ЭАК система центра обслуживания. Руководство пользователя.
advertisement
СИСТЕМА ЦЕНТРА ОБСЛУЖИВАНИЯ. Руководство пользователя. (HP Open View Service Desk 4.5) Аннотация. Данное руководство, в первую очередь, предназначено для общего ознакомления технических специалистов компании с программным обеспечением HP Open View Service Desk 4.5. Часть используемой терминологии является специфичной для нашей компании и может не совпадать с вашей терминологией или общепринятой. Данное руководство проводит только обзор и только основного функционала системы, многое при этом, конечно, осталось «за кадром». В данном руководстве пока, к сожалению, существуют ошибки и неточности, но по мере наличия времени и желания, а также замечаний и пожеланий я постараюсь ошибки исправлять, и, конечно, само руководство улучшать. Основным источником при написании служило оригинальное руководство пользователя HP Open View Service Desk 4.5, также иногда заглядывал в ITIL Service Support, ITIL Service Delivery… 2 Содержание. 1. ВВЕДЕНИЕ В СИСТЕМУ ЦЕНТРА ОБСЛУЖИВАНИЯ. ............................................ 10 Что представляет собой система центра обслуживания? .................. 10 Запуск системы центра обслуживания (service desk). ................... 10 Использование центра обслуживания (service desk). .................... 11 Консоль центра обслуживания (service desk). .......................... 11 Работа системы центра обслуживания. .................................. 15 Функциональная структура системы центра обслуживания (service desk). . 15 Нацеленность на результат. ........................................... 15 Техническая структура системы центра обслуживания (service desk). .... 16 Обеспечение высокого качества приложения. ............................ 16 Гарантированная гибкость использования. .............................. 17 2. КОНЦЕПЦИЯ СИСТЕМЫ. ......................................................................................... 18 Основные концепции. .................................................. 18 ITIL и система центра обслуживания. .................................. 20 Понимание процессов системы центра обслуживания. ..................... 20 Роли пользователей системы центра обслуживания. ...................... 22 Пользователи. .......................................................................................................................... 22 Клиенты....................................................................................................................................... 22 Контактные лица.................................................................................................................... 23 Специалисты. ............................................................................................................................ 23 Организация. ............................................................................................................................ 24 Менеджеры конфигураций. .................................................................................................. 24 Менеджеры изменений. ......................................................................................................... 24 Менеджеры проблем. .............................................................................................................. 24 Менеджеры уровня обслуживания. ................................................................................. 25 Администраторы персон и организаций. ................................................................... 25 Администраторы приложений и системные администраторы. .......................... 26 3. ВОЗМОЖНОСТИ СИСТЕМЫ ЦЕНТРА ОБСЛУЖИВАНИЯ. .......................................... 27 Шаблоны. ............................................................. 27 Утверждение. ......................................................... 29 Введение в утверждения. .............................................. 29 Листы утверждений. ................................................... 32 Роли утверждающих. ................................................... 34 Пример утверждения проводимого изменения. ....................................................... 35 3 Управление работами. ................................................. 38 Сервис сегодня. ...................................................... 38 Наряды. .............................................................. 38 Назначение. .......................................................... 39 Жизненный цикл и коды состояний. ..................................... 39 Каталоги и категории. ................................................ 40 Каталоги. ................................................................................................................................... 41 Категории. ................................................................................................................................. 41 Интернациональная система центра обслуживания. ....................... 44 Гибкость системы центра обслуживания. ................................ 45 Консоль системы центра обслуживания. ................................. 47 Введение в сервисные страницы. ....................................... 48 4. ОСНОВНЫЕ ЗАДАЧИ. ............................................................................................. 51 Просмотр информации. ................................................. 51 Использование формата таблицы. ....................................... 51 Формат графиков.................................................................................................................... 52 Формат обозревателя. ......................................................................................................... 53 Формат карт. ............................................................................................................................ 54 Формат иерархии (дерева). ............................................................................................. 54 Формат проекта. ..................................................................................................................... 55 Использование меню действий. ......................................... 57 Использование расширенного поиска. ................................... 57 5. ЗАДАЧИ ПОЛЬЗОВАТЕЛЯ. ..................................................................................... 62 Пример. Регистрация обращения. ................................................................................. 62 Каково решение? ...................................................... 62 Администрирование обращений. ......................................... 62 Регистрация обращений. ............................................... 62 Использование сервисных страниц. ..................................... 63 6. ЗАДАЧИ ПЕРСОНАЛА ТЕХНИЧЕСКОЙ ПОДДЕРЖКИ. ............................................ 64 Пример. Работа оператора технической поддержки. ......................................... 64 Обзор задач оператора технической поддержки. ......................... 64 Администрирование обращений. ......................................... 65 Регистрация обращений. ............................................... 65 Проведение анкетирования. ............................................ 67 4 Просмотр обращений. .................................................. 67 Обновление обращений. ................................................ 67 Создание обращений субподрядчику. .................................... 67 Закрытие обращения. .................................................. 67 Пример. Создание обращения. ........................................................................................ 68 Зависимости процессов системы центра обслуживания. ................... 73 Зависимости ролей системы центра обслуживания. ....................... 74 7. ЗАДАЧИ МЕНЕДЖЕРА КОНФИГУРАЦИЙ. ............................................................... 76 Администрирование конфигурационных единиц. ........................... 76 Категоризация конфигурационных единиц. ............................... 76 Регистрация конфигурационных единиц. ................................. 77 Использование формы новой конфигурационной единицы. .................. 77 Использование помощника генерации конфигурационных единиц. ........... 79 Просмотр конфигурационных единиц. .................................... 79 Обновление конфигурационных единиц. .................................. 79 Определение плановых простоев. ....................................... 80 Удаление конфигурационных единиц. .................................... 80 Зависимости конфигурационных единиц. ................................. 81 Пример. Пакетная регистрация КЕ. ............................................................................ 81 Определение ролей, относящихся к системе центра обслуживания. ........ 87 8. ЗАДАЧИ СПЕЦИАЛИСТА. ....................................................................................... 89 Администрирование действий специалистов. ............................. 89 Принятие обращений. .................................................. 89 Просмотр обращений. .................................................. 90 Обновление обращений. ................................................ 90 Закрытие обращения. .................................................. 90 Создание обращений субподрядчику. .................................... 91 Пример. Создание обращения субподрядчику включённого в предоставление операционного уровня услуг. ..................................................... 91 Пример. Создание обращения субподрядчику включённого в предоставление бизнес-услуг. ...................................................................................... 91 Зависимости элементов системы центра обслуживания. ................... 92 Пример. Анализ проблемы................................................................................................. 92 Определение зависимых ролей системы центра обслуживания. ............. 95 5 9. ЗАДАЧИ МЕНЕДЖЕРА ИЗМЕНЕНИЙ. ...................................................................... 97 Администрирование изменений. ......................................... 97 Утверждение изменений. ............................................... 97 Просмотр изменений. .................................................. 98 Обновление конфигурационных единиц. .................................. 98 Закрытие изменений. .................................................. 98 Планирование периодических простоев. ................................. 99 Передача информации в HP Open View Operations. ...................... 101 Обновление КЕ согласно наряду. ...................................... 101 Указание планируемых значений атрибутов. ............................ 101 Назначение менеджера изменений. ..................................... 103 Проверка зависимости КЕ с другими нарядами на изменения. ............ 103 Пример. Планирование изменения. ............................................................................. 104 Идентификация зависимых ролей системы центра обслуживания. .......... 105 10. ЗАДАЧИ МЕНЕДЖЕРА ПРОБЛЕМ. ...................................................................... 107 Администрирование задач менеджера проблем. .......................... 107 Регистрация проблем. ................................................ 108 Зависимости элементов системы центра обслуживания. .................. 110 Пример. Регистрация проблемы. .................................................................................. 111 Пример. Инициация изменения. .................................................................................... 113 Идентификация зависимых ролей системы центра обслуживания. .......... 115 11. ЗАДАЧИ МЕНЕДЖЕРА УРОВНЯ ОБСЛУЖИВАНИЯ. ............................................ 117 Определение структуры сервисов. ..................................... 117 Типы сервисов. ...................................................... 117 Сервисы операционного управления. ................................... 118 Подпирающие сервисы. ................................................ 118 Зависимости сервисов. ............................................... 118 Зависимость типа «родительский-дочерний». ........................... 118 Зависимость типа «использует-используем». ........................... 119 Зависимость типа «управляющий-управляем». ........................... 119 Зависимость типа «поддерживающий-поддерживаем». ..................... 119 Зависимость типа «подпирающий-подпираем». ........................... 119 6 Допустимые структурные зависимости для сервисов и КЕ. ............... 119 Пример. Определение структуры сервисов. .......................................................... 120 Автоматическое получение уровней обслуживания в инцидентах. ......... 122 Инциденты, связанные с сервисом. .................................... 123 Инциденты, связанные с конфигурационными единицами. ................. 124 Добавление сервисов операционного управления и подпирающих сервисов в структуру сервисов. ................................................. 124 Создание эффективных соглашений об уровне услуг. .................... 125 Определение расписания обслуживания соглашения об уровне обслуживания. .................................................................... 126 Составление соглашения об уровне услуг. ............................. 127 Элементы соглашения об уровне обслуживания. ......................... 128 Оценка соответствия соглашению об уровне обслуживания. .............. 129 Внутренняя и внешняя оценка. ........................................ 129 Типы оценки производительности. ..................................... 130 Доступность сервиса. ....................................................................................................... 130 Данные анализа производительности. ...................................................................... 130 Производительность планирования. .......................................................................... 130 Учёт запасов производительности сервисов. ........................... 130 Идентификация зависимых ролей системы центра обслуживания. .......... 131 12. ЗАДАЧИ АДМИНИСТРАТОРА ПЕРСОН И ОРГАНИЗАЦИЙ. ............................... 132 Администрирование персон и организаций. ............................. 132 Категоризация персон и организационных структур. .................... 133 Регистрация персон и организаций. ................................... 133 Создание записи персон. ............................................. 134 Создание записей организации. ....................................... 135 Создание записи рабочей группы. ..................................... 135 13. ИСПОЛЬЗОВАНИЕ СРЕДСТВ ЭЛЕКТРОННОЙ ПОЧТЫ ДЛЯ УПРАВЛЕНИЯ ДАННЫМИ. ................................................................................................................... 137 Отправка сообщений электронной почты системе центра обслуживания. ... 137 Использование входящей электронной почты. ........................... 138 Использование команды «New». .................................................................................... 138 Использование команды «Update<id>». ................................................................... 138 Использование команды «Add History Line<id>»............................................. 139 Использование команды «View <id>». ...................................................................... 140 Использование команды «List»................................................................................... 140 Использование команды «RE:RFI<id>». ................................................................... 140 7 Использование Использование Использование Использование команды команды команды команды «RE:Solution Accepted <id>»................................. 140 «RE:Solution Rejected <id>»................................. 141 «Recall <id>». ................................................................. 141 «Help»................................................................................... 141 8 Версия Дата 1 20.10.06 Обновлено Гнедыш Д.Е. Комментарии Начальная редакция документа. 9 1. Введение в систему центра обслуживания. Данная глава предоставляет краткий обзор системы центра обслуживания (service desk). Так же описывается техническая и функциональная структура системы и её использование. Что представляет собой система центра обслуживания? HP Open View Service Desk позволяет автоматизировать действия, связанные с процессом управления инфраструктурой ИТ и контролем качества предоставления критичных бизнес-услуг. Поддерживаемый процесс управления ИТ должен быть управляем с помощью определённых уровней обслуживания. Данные уровни обслуживания устанавливаются договорными отношениями с потребителями услуг ИТ (напр. договор обслуживания). Уровни обслуживания должны быть понятны потребителям и приняты потребителями услуг ИТ. Система центра обслуживания (service desk) позволяет: Увеличить качество и количество предоставляемых услуг ИТ. Уменьшить время решения возникающих инцидентов, проблем, обращений. Предотвратить возникновение повторяющихся инцидентов, обращений, проблем. Уменьшить риски, связанные с расширением и изменением инфраструктуры ИТ. Управлять процессами, связанными с предоставлением высокого уровня обслуживания ИТ. Система центра обслуживания (service desk) является структурированным, объектно-ориентированным приложением, предоставляющим набор инструментов для управления услугами поддержки ИТ, предоставления отчётности и улучшения всех процессов, связанных с обслуживанием инфраструктуры ИТ. Программное обеспечение может быть уникально настроено для соответствия любым процедурам любых департаментов ИТ. Также приложение может быть интегрировано с множеством утилит, для дальнейшего расширения функциональных возможностей. Запуск системы центра обслуживания (service desk). При выполнении первого запуска клиентской части системы центра обслуживания (service desk) приложение пытается установить соединение с сервером приложений с информацией, хранимой на вашем локальном компьютере в профиле пользователя. Если консоль центра обслуживания (service desk) не находит информации в профиле пользователя, то вызывается помощник настройки соединения консоли центра обслуживания (service desk) с сервером приложений. 10 Если информация соединения найдена на вашем компьютере, консоль центра обслуживания автоматически устанавливает соединение с сервером приложений и отображает консоль центра обслуживания. Если информация, хранимая на вашем компьютере, является некорректной – отображается окно ввода учётной записи. В зависимости от того, каким образом администратор системы сконфигурировал сервер приложений центра обслуживания, возможно, потребуется дополнительный процесс аутентификации пользователя. Когда запускается консоль центра обслуживания (service desk), окно аутентификации запрашивает имя пользователя, пароль, NetBIOS-имя или IP-адрес сервера приложений. Использование центра обслуживания (service desk). Консоль центра обслуживания (service desk). Консоль является начальной точкой, для большинства задач, связанных с системой центра обслуживания (service desk). 11 Консоль представляет собой графический интерфейс приложения. Отображаемая в консоли информация является визуальным представлением информации, хранимой в базе данных. Консоль является основным инструментом для ввода и управления информацией, хранимой в базе данных. В верхней части консоли отображается стандартный заголовок окна. В заголовке окна отображено «Центр обслуживания», в правой части заголовка окна находятся стандартные кнопки операционной системы Windows для закрытия и изменения размеров окна. Под заголовком окна вы можете видеть одну или более инструментальных панелей. Вы можете использовать инструментальную панель для выполнения команд. Существует два различных типа инструментальных панелей: панель меню и панель кнопок. На панели меню, команды представлены именами и сгруппированы в блоки меню. В панели 12 кнопок команды представлены пиктограммами. Команды, запускаемые с помощью инструментальной панели, могут изменяться в зависимости от типа отображаемой информации в консоли. Инструментальные панели могут быть настроены пользователем самостоятельно. Наименование команд и их размещение может быть настроено под конкретные требования организации. Под инструментальной панелью вы можете видеть данные и панель ссылок. Панель ссылок расположена с левой стороны консоли: Для отображения различной информации в консоли необходимо выбрать определённые пиктограммы. Каждая пиктограмма ссылки представляет различные представления данных или ссылку на внешние приложения, такие как, например, Microsoft® Word. Одна или более пиктограмм могут быть сгруппированы. Группа является подмножеством пиктограмм. Вы можете удалять, редактировать или добавлять группы для соответствия вашим требованиям. Для отображения группы необходимо нажать на отображаемый заголовок группы. Область данных отображает хранимую информацию. Для управляемой вами информации область данных предоставляет набор записей системы центра обслуживания (service desk). Например, изображённый ниже рисунок показывает обзор всех запросов на изменения по определённой конфигурационной единице (HP Open View Service Desk, в данном случае). 13 Система центра обслуживания может отображать хранимую информацию в нескольких форматах представления: Табличное представление. Отображает записи, следующие друг за другом, в форме списка. Для каждой записи значения определённых атрибутов отображаются последовательно. Иерархическое представление. Отображает информацию в иерархической форме. Графическое представление. Отображает информацию в форме различных форматов диаграмм, включая линейные диаграммы, круговые диаграммы и гистограммы. Карточное представление. Отображает информацию в виде отдельных карточек. Представление обозревателя. Отображает информацию в виде совокупности информационных панелей. Основная информация отображается на главной панели. Навигационная панель позволяет осуществлять переходы между информацией. Вспомогательные панели отображают детализированную информацию выбранного пункта главной панели. Для более детальной информации об использовании см. главу «Отображение информации». Вы можете перейти к редактированию записи двойным нажатием (double click) на элемент или линии в области данных. Например, если вы произведёте двойное нажатие на элементе «запрос на изменение» с номером 4, то подробности данного изменения будут отображены в следующей форме: 14 Работа системы центра обслуживания. Функционально, система центра обслуживания разделена на набор ключевых модулей, в то время как технически система разделена на совокупность уровней. Понимание структуры системы центра обслуживания поможет вам понять логику приложения и предотвратить возникновение проблем. Функциональная структура системы центра обслуживания (service desk). Каждый процесс системы центра обслуживания поддерживается соответствующим модулем. Объединение групп различных модулей образуют решение для одной определённой задачи системы центра обслуживания. Нацеленность на результат. При внедрении эффективного управления инфраструктурой ИТ возникают следующие вопросы: Как предоставить эффективные и рациональные услуги ИТ? Как вести учёт конфигурационных единиц (активов) ИТ? Как управлять расширением и изменением инфраструктуры ИТ? Как обрабатывать поступающие запросы пользователей? 15 В зависимости от масштабов инфраструктуры ИТ, вы можете столкнуться с одним или более подобных вопросов, управляя инфраструктурой ИТ. Например, когда вы, сидя дома, используете свой домашний компьютер для написания писем или управляете сетью в 3000 или более компьютеров в большой компании, в зависимости от типа используемого вами компьютера, вы должны потратить определённое время на его обслуживание. Компьютер должен работать и быть корректно настроен. Соответственно, настройки операционной системы должны быть корректны для гарантии работоспособности компьютера. Если кто-то провёл изменение в конфигурации компьютера, то время, которое необходимо вам для возвращения его в работоспособное состояние, может быть значительным. Вы можете даже рассмотреть вопрос приобретения дополнительных компьютеров для членов вашей семьи. Пример приведённый выше иллюстрирует эффективность стоимости сервиса. Например, сервис доступности текстового редактора, пока ваш ребёнок не занялся компьютером. Эффективность стоимости, в данном примере, выражена во времени, которое необходимо потратить на восстановление параметров текстового редактора и операционной системы, по сравнению с фактическим временем использования текстового редактора. Когда вы попробуете произвести масштабирование данного примера на крупную компанию в 3000 и более компьютеров, то можете оценить возрастающую ответственность за быстроту принятия решений. Вы должны сфокусироваться на предоставлении решений и система центра обслуживания поможем вам в этих целях. Техническая структура системы центра обслуживания (service desk). Для оптимизации производительности и масштабируемости, система центра обслуживания использует трёхзвенную архитектуру, состоящую из следующих частей: Сервер баз данных (Oracle RDBMS, MS SQL). Сервер приложений (Apache, TomCat, Java). Клиент (Java). Основная логика приложения реализована на сервере приложений и клиенте. Обеспечение высокого качества приложения. Система центра обслуживания разработана с использованием объектно-ориентированной методологии, используя объектноориентированный язык программирования Java. Пользовательский интерфейс системы центра обслуживания использует для работы виртуальную машину Java (JVM). Дополнительный функционал производит проверку версий пользовательских классов при старте системы. При наличии более новых пользовательских классов они загружаются и устанавливаются автоматически. В зависимости от количества пользовательских классов, проверка и установка обновлений может занять некоторое 16 время. Данная функциональность гарантирует использование только последних версий пользовательских классов. Гарантированная гибкость использования. Гибкость в использовании системы центра обслуживания предоставляется двумя путями: Минимизация сетевого трафика. Уменьшенная нагрузка на сеть позволяет СУБД обслуживать большее количество клиентов. Благодаря клиент-серверному построению системы центра обслуживания (service desk), вы можете использовать систему где угодно, используя, например, модем, и при этом иметь приемлемое время отклика системы. 17 2. Концепция системы. Данная глава производит краткий обзор основных концепций и пользовательских ролей в системе центра обслуживания (service desk). Понимание концепций, на которых базируется система центра обслуживания (service desk), является важной составляющей в процессе внедрения и использования системы. Основные концепции. Система центра обслуживания основана на использовании методологии ITIL. ITIL (библиотека инфраструктуры ИТ) была создана в CCTA (центральным агентством по компьютерам и телекоммуникациям Великобритании), для выработки согласованных стандартов качества предоставления услуг ИТ. ITIL помогает организациям улучшить процесс управления инфраструктурой ИТ. Это наиболее всеобъемлющее руководство из существующих по предоставлению услуг ИТ. Использование ITIL или аналогичной методологии предоставления услуг ИТ, является ключевым фактором, при выполнении обязательств по предоставлению качественных услуг ИТ конечным пользователям. Авт. Основой ITIL является совокупность взаимосвязанных процессов управления инфраструктурой, поддержки инфраструктуры, предоставления услуг и пр. Основой ITIL является процессный подход к управлению. В данном руководстве, кроме стандартных процессов поддержки, описывается не входящий в ITIL процесс управления обращениями. 18 ITIL описывает некоторые аспекты управления сервисами, например, поддержку и предоставление сервисов, управление ИТ инфраструктурой, управление приложениями, а также требования бизнеса к предоставлению услуг ИТ. Каждый элемент сфокусирован на некотором диапазоне направлений. Например, поддержка сервисов (ITSM) сфокусирована на процессе (функции) центра обслуживания (service desk), которая, в свою очередь, состоит из ряда процессов таких как: Управление инцидентами. Управление конфигурациями. Управление изменениями. Управление проблемами и пр. Концепции, на которых базируется ITIL и другие успешные методологии, состоит в осознании организацией возрастающей зависимости от услуг ИТ, удовлетворяющих потребности бизнеса. Зависимость от услуг ИТ требует наличия качественной инфраструктуры ИТ и процессов управления сервисами. Качество предоставления услуг должно соответствовать требованиям бизнеса и конечных пользователей. 19 Процессы ITIL предоставляют основу для качественного управления услугами и инфраструктурой ИТ. Лучшие практики ITIL описывают каким образом предоставить качественные услуги ИТ при влиянии таких факторов как: Отсутствие должной квалификации персонала. Ограничения бюджета. Сложность системы. Высокие требования пользователей. ITIL и система центра обслуживания. Система центра обслуживания (service desk) разработана специально для компаний и подразделений, ответственных за предоставление и поддержку сервисов ИТ. Система центра обслуживания (service desk) управляет процессами, которые определяют, устанавливают, документируют и управляют услугами, предоставляемыми пользователям. Потребителям услуг ИТ требуется поддержка, и центр обслуживания (service desk) предоставляет средства, гарантируя, что предоставляемые услуги поддерживаются экономически эффективно. Вы можете использовать систему центра обслуживания для задач эффективного управления предоставлением услуг ИТ, управления инфраструктурой и центром поддержки пользователей. Центр обслуживания (service desk), поддерживает следующие функции и процессы, основанные на методологии ITIL: Центр обслуживания. Управление инцидентами. Управление проблемами. Управление изменениями. Управление уровнем обслуживания. Управление конфигурациями. Подробности данных процессов будут обсуждаться позже в данном руководстве. Краткое описание будет приведено в следующей главе. Понимание процессов системы центра обслуживания. Пользовательское обращение (origin. service call) –обращение пользователя, не связанное с отклонениями работы системы от штатного функционирования (Пример. Предоставление документации, консультации по возникающим вопросам эксплуатации чего-либо и т.п.). После того как обращение получено и внесено в систему, оно постоянно добавляется информацией, в ответ на запросы пользователя. В HP Open View Service Desk обращением также является информация, поступающая из определённых источников, например, «e-mail-интерфейс». При получении сообщения по электронной почте, система автоматически классифицирует его как обращение. Инцидент (origin. incident) – некоторое негативное операционное событие не являющиеся частью штатного функционирования системы. 20 Управление инцидентами является процессом документирования, мониторинга и разрешения инцидентов для скорейшего восстановления штатной работоспособности системы. В данном случае слово «система» не ограничено понятиями только аппаратной части инфраструктуры ИТ; системой может являться что угодно, включенное в процесс предоставления услуг. Это может включать в себя не только аппаратное обеспечение, но и такие неосязаемые вещи как, например, квалификация специалистов включённых в процесс предоставления услуг ИТ. Проблема (origin. problem) – неизвестная причина возникновения одного или более инцидентов, существенное, по степени влияния и воздействия, негативное отклонение системы от штатного функционирования. Управление проблемами – это процесс анализа инцидентов для идентификации корневых причин их возникновения. Исследование и разрешение неизвестных причин является частью решения проблем. В то время, как решение инцидентов является узкой задачей, направленной, в основном, на решение индивидуальных инцидентов в минимальные сроки, управление проблемами использует соответствующие технологии и имеющуюся информацию для локализации причин их возникновения. Как только будет найдена корневая причина возникновения проблемы, может быть инициировано изменение, для упреждения повторений возникновения новых инцидентов. Процесс управления проблемами также может быть ограничен идентификацией корневой причины без проведения изменения по ряду причин. В таком случае проблема становится известной ошибкой. Известная ошибка может быть рассмотрена как одно из состояний проблемы. Изменение (origin. change) – санкционированное добавление, модификация или удаление, поддерживаемого или основного аппаратного обеспечения, элементов сетевой инфраструктуры, программного обеспечения, приложений, систем и сопровождающей документации. Всё, что относится к предоставлению услуг в поддержке инфраструктуры ИТ, может быть изменено, включая сервисы и соглашения об уровнях обслуживания. Управление изменениями – процесс контроля и управления изменениями с момента регистрации изменения и до окончания проведения изменения. Изменение может быть инициировано через процесс управления проблемами или как автономное изменение не связанное с проблемой, изменением или обращением. Управление изменениями рассматривает вопрос целесообразности выполнения изменения и если проведение изменения утверждено, то оно проводится. Изменения могут логически группироваться в проекты. Конфигурационная единица (origin. Configuration Item) – отображает произвольные объекты с произвольной степенью детализации в используемой инфраструктуре ИТ. Совокупность конфигурационных единиц отображает рабочее окружение инфраструктуры ИТ для сотрудников подразделения поддержки ИТ и, возможно, ваших заказчиков. Конфигурационные единицы не обязательно относятся только к аппаратному обеспечению. Управление конфигурационными единицами – это процесс контроля и 21 управления конфигурационными единицами на протяжении всего жизненного цикла конфигурационной единицы (КЕ). Жизненный цикл КЕ начинается с процедуры закупки или создания и заканчивается процедурой списания. Управление уровнем услуг (origin. Service Level Management) – это процесс определения, принятия, документирования, управления и обоснования стоимости предоставляемых уровней услуг. Соглашение об уровне услуг (origin. Service Level Agreement) описывает достигнутые договорённости между поставщиками услуг ИТ и потребителями, об уровнях предоставления услуг ИТ. Краткое и однозначное содержание соглашения об уровне услуг облегчает толкование соглашения, как поставщику услуг ИТ, так и потребителю. Роли пользователей системы центра обслуживания. Множество людей задействованы в процессе внедрения и использования системы центра обслуживания. Роли определяют права и ответственность, которыми наделены пользователи системы центра обслуживания. Основными ролями системы центра обслуживания являются: Пользователи. Клиенты. Контактные лица. Специалисты. Менеджеры конфигураций. Менеджеры изменений. Менеджеры проблем. Менеджеры уровней обслуживания. Администраторы персон и организаций. Администраторы приложений и системные администраторы. Пользователи. Пользователи являются непосредственными потребителями услуг. Внутренние или внешние пользователи могут и не знать об использовании системы центра обслуживания службой технической поддержки. Они могут контактировать с технической поддержкой по телефону, факсу, электронной почте или с помощью обозревателя Интернет. Клиенты. Предоставляемые клиенту услуги являются предметом достигнутых соглашений с заказчиком. Заказчики могут быть как индивидуальными потребителями услуг, так и отдельными подразделениями компаний или компанией в целом. Поставщики услуг ИТ, в данном случае, чаще проводят управление услугами ИТ на уровне сервиса, чем на уровне отдельного потребителя данного сервиса. 22 Контактные лица. Контактные лица включаются в использование системы центра обслуживания тогда, когда определённые договором услуги внедряются или предоставляются. Контактное лицо является посредником между обеими сторонами договора. Контактные персоны в основном работают по следующим двум сценариям: Поставщик услуг предоставляет услуги по договору. В данном сценарии, контактное лицо является связью между потребителями услуг ИТ и поставщиками. Контактная персона предоставляет первую линию поддержки. Если квалификации или полномочий контактного лица недостаточно для решения возникающих проблем, контактное лицо направляет запрос профильному специалисту или производит эскалацию. Поставщик услуг заключает договор предоставления услуг. В данном сценарии, контактное лицо является каналом связи между поставщиками услуг и субподрядчиками. Контактная персона, в данном случае, ответственна за все входящие и исходящие запросы поставщиков услуг. По данным примером видно, что контактное лицо является ответственным лицом за непосредственное исполнение заключённого договора. Контактное лицо связывает различных поставщиков услуг ИТ в единый процесс предоставления решения ИТ. Специалисты. Специалисты являются персонами, которые включены в процесс сопровождения, с целью предоставления услуг ИТ определённого уровня качества. Специалисты, как правило, работают по определённому направлению, по которому имеют необходимую квалификацию. Специалисты могут выполнять специализированные задачи по обслуживанию инфраструктуры ИТ и предоставлению услуг. Специалисты могут быть сгруппированы по специализации. Широко известными специализациями являются: Прикладное программное обеспечения (АИИС КУЭ, САПР, ERP). Аппаратное обеспечение серверов и/или рабочих станций. Сетевая инфраструктура. Безопасность. Системы управления базами данных. Перечень специализаций вашей компании может отличаться от вышеперечисленного перечня специализаций. Определение специализаций зависит от нужд потребителей и предоставляемых компанией услуг. Специалисты, также, могут быть сгруппированы в рабочие группы. Специализация не является критичным фактором для поставщиков услуг ИТ и может быть отдана на субподряд. Субподрядчик, основным бизнесом которого является отдаваемое ему направление, 23 не является специалистом или рабочей группой. Субподрядчик является внешней компанией, предоставляющей определённый пакет услуг, имеющей контактную персону для связи. Организация. Все вышеперечисленные роли являются составной частью организации. Организация отображает компанию, работником которой является каждая персона. Обычно организационная структура регистрируется в системе центра обслуживания, отталкиваясь от существующей структуры компании. Менеджеры конфигураций. Менеджеры конфигураций способствуют в предоставлении организацией качественных услуг ИТ, контролируя и управляя активами ИТ компании. В служебные обязанности менеджера конфигураций входит: Управление и контроль над всеми конфигурационными единицами. Обслуживание записей, относящихся к конфигурационным единицам. Аудит инфраструктуры ИТ с целью обнаружения наличия несанкционированных конфигурационных единиц. Поддержка в проведении изменений конфигурационных единиц. Менеджеры изменений. Менеджеры изменений гарантируют, что изменения в бизнес-системах являются контролируемыми и выполняемыми. События, требующие внесения изменений в систему: При проблемах, вызванных инцидентами или отчётом о проблемах. Возникновение претензий пользователей. Введение новых конфигурационных единиц. Обновление компонентов. При возникновении новых требований бизнеса. При изменении законодательства. Возникновения новых продуктов или услуг. Менеджер изменений контролирует и производит оценку эффективности центра обслуживания на каждом этапе деятельности. Менеджеры проблем. Ответственность менеджера проблем может быть разделена на пять основных областей деятельности: Контроль инцидентов. Предоставление второй линии для группы технической поддержки в процессе диагностики и решения инцидентов, а также координация с другими группами специалистов. Контроль проблем. Идентификация, диагностика и документирование корневых причин возникновения инцидентов 24 для предотвращения их повторного возникновения и избежание возникновения потенциальных проблем. Контроль над ошибками. Процесс устранения и коррекции возникающих с инфраструктурой ИТ проблем. Проактивный мониторинг. Выполнение действий по устранению потенциальных проблем до их возникновения. Управление информацией управляющих операционных процессов. Менеджеры уровня обслуживания. Менеджеры уровня обслуживания специализируются на предоставлении качественных услуг ИТ, соответствующих запросам потребителей услуг ИТ. Менеджер уровня обслуживания должен понимать сложность взаимосвязей между внутренними и внешними сервисами, должен составлять соответствующие соглашения об уровне обслуживания, должен отслеживать выполнение ключевых показателей (KPI) данных соглашений, чтобы поставщики услуг и потребители могли выполнять анализ соответствия. В процессе идентификации и анализа взаимосвязей сервисов, менеджер уровня обслуживания должен руководствоваться следующими принципами: Сервисы могут быть разделены на составляющие части, которые могут предоставляться как целиком, так и по отдельности. Бизнес-сервисы часто используют или поддерживают другие бизнес-сервисы. Обслуживаемые сервисы, использующие конфигурационные единицы, могут быть задействованы бизнес-сервисами. Некоторые аспекты обслуживания сервисов могут производиться сторонними организациями. Данные действия должны подкрепляться соответствующими договорными отношениями. При составлении соглашения об уровне обслуживания, менеджер уровня обслуживания должен учесть следующие факторы: Качество предоставления услуг. Экономическая эффективность предоставляемых услуг. Соответствие предоставляемых услуг ожиданиям бизнеса, потребителей и заказчиков. Интеграция с центром обслуживания. Определение ролей и зон ответственности в процессе предоставления услуг. Определение ключевых показателей производительности сервисов. Администраторы персон и организаций. Администраторы персон и организаций компании должны гарантировать, что записи элементов пользователей инфраструктуры ИТ и персонала центра обслуживания в системе центра обслуживания являются актуальными. Информация о персонале центра обслуживания должна контролироваться для выполнения обязательств по заданным уровням обслуживания. В зависимости от требований бизнеса, 25 следующие события могут влечь за собой добавление или удаление элементов персон и организаций в системе центра обслуживания: Найм/Увольнение сотрудника центра технической поддержки. Новый пользователь. Новый заказчик. Администратор персон и организаций контролируют и определяют степень детализации данных по элементам пользователи и персонал центра технической поддержки на каждом из этапов. Так как каждая конфигурационная единица является активом, относящимся к организации или пользователю, целостность информации по элементам «персона» и «организация» является одной из первостепенных задач. Администраторы приложений и системные администраторы. Системные администраторы и администраторы приложений (например, администраторы АСКУЭ) определяют и обслуживают стандартную установку параметров системы центра обслуживания. По согласованию с управляющими инфраструктурой ИТ, системные администраторы и администраторы приложений сопровождают общее заполнение и отображение информации в системе центра обслуживания. Например, в задачи системного администратора может входить управление учётными записями, распределение полномочий и управление ролями в системе центра обслуживания. Часто задачи системного администратора и администратора приложений могут быть выполнены консультантами. 26 3. Возможности системы центра обслуживания. Данная глава рассматривает основные возможности системы центра обслуживания по поддержке выполнения бизнес-процессов компании. Шаблоны. Во время создания нового элемента системы центра обслуживания, в него копируются начальные значения, находящиеся в шаблоне. После того, как элемент будет создан, вы можете редактировать эти поля, а также добавлять дополнительную информацию. Каждый тип элемента имеет не менее одного шаблона. Вы можете добавить дополнительные шаблоны каждому типу элементов для выполнения специфических задач, например, могут быть созданы шаблоны обращений по приёму нового сотрудника или созданию новой учётной записи в системе. Система центра обслуживания предоставляет шаблоны, которые могут быть настроены и в дальнейшем использованы как часть вашего решения. Используя стандартные шаблоны, вы можете ускорить разработку Вашего решения и улучшить процесс разработки незамедлительно. Например, шаблон соглашения об уровне обслуживания может быть использован для предоставления некоторого оценочного периода: 27 Каждый раз, когда создаётся соглашение об уровне обслуживания, значение оценочного периода, указанное в шаблоне, автоматически размещается в указанном поле формы. Вы можете настроить любой шаблон для представления информации соответствующей бизнес-стратегии компании. Шаблоны могут быть настроены для установки зависимостей с существующими элементами или использованы при выполнении триггерной логики создания новой зависимости. Например, обращение с причиной восстановления пароля пользователя может автоматически заводить наряд на работы по генерации пароля. Шаблоны должны регулярно пересматриваться и при необходимости изменяться, чтобы соответствовать последним требованиям бизнеса. 28 При создании большого количества шаблонов можно воспользоваться возможностью группировки шаблонов. Утверждение. Предоставление критичных бизнес-процессов ИТ зависит от быстрого принятия решений. Для получения полномочий на обслуживание сервисов процесс управления ИТ должен выполнить несколько шагов. Гарантировать, что соответствующие специалисты включены в процесс принятия решений до этапа внедрения, является одним из ключевых факторов производительности процесса. Авторизация процесса управления ИТ является неэффективным действием и занимает много времени при отсутствии автоматизации выполняемых действий. Система центра обслуживания предоставляет структурированный, процессно-ориентированный механизм утверждения для управления и авторизации процессов управления ИТ. Введение в утверждения. Утверждение предоставляет возможность автоматически запрашивать авторизацию при условиях требующих выполнение действия. Например, при наличии необходимости внесения изменений в сетевую инфраструктуру, каким образом соответствующие специалисты будут уполномочены выполнить данное действие в заданные сроки? Утверждение гарантирует, что предполагаемые действия обеспечиваются автоматически в соответствии со стратегией утверждений компании. Процесс утверждения проводится с использованием листа утверждений. Начальный статус листа утверждения «Неактивный». В этом состоянии лист утверждения отображает максимальное время для утверждения и список лиц, которые должны провести утверждение. Статус листа утверждения изменяется с «Неактивный» на «Активный» в начале процесса утверждения. Утверждающие персоны могут просмотреть все элементы, ждущие их утверждения, выбором соответствующих отображений, таких как «Задачи утверждения для текущей персоны» в меню «Сервис сегодня». 29 Утверждающие персоны могут воспользоваться поиском элементов, требующих их утверждения используя вкладку «Расширенный выбор» в диалоговом окне «Расширенный поиск». Пользователи, также, могут выбрать вариант уведомления по электронной почте о требуемых задачах утверждения. 30 Затем утверждающие голосуют, выбирая параметры «Да» или «Нет». Результаты утверждения автоматически заносятся в таблицу и, когда достаточное количество утверждающих авторизует действие, статус утверждения автоматически становится «Утверждено». Результат утверждения указывает на окончание задачи утверждения и, если утверждение положительное, действие может быть выполнено. Если утверждающие в течение определённого периода времени утверждения не провели утверждение – статус листа утверждений автоматически принимает статус «Выполнено». Результат утверждения, конечно, принимает статус «Отклонено». 31 Листы утверждений. Листы утверждений могут быть добавлены в наряды, изменения, проекты, проблемы, инциденты, и обращения. Лист утверждения используется инициатором утверждения в начале процесса утверждения, и используется как бюллетень для формирования списка утверждающих персон. 32 Хотя лист утверждений может быть настроен администраторами системы центра обслуживания, но по умолчанию лист утверждений состоит из следующих полей: Статус голосования. Статус утверждения может принимать значения «Активный», «Неактивный» или «Утверждено». Крайний срок. Это последнее число, когда может быть проведено утверждение. #Утверждающих. Минимально необходимое количество положительных утверждений необходимых специалистам для начала выполнения работ. Стратегия. Стратегия утверждения рассматривает, какое количество утверждений необходимо получить по отношению к общему количеству специалистов, которые проводят утверждение действий. Например, если 10 специалистов были назначены для проведения утверждения выполняемого действия и только один специалист должен утвердить – тогда стратегия организации рассматривается как 1 из 10. Описание. Это свободное текстовое поле, которое содержит любую информацию, относящуюся к утверждению. Например, зачем требуется проведение изменения или любая другая информация, которая может помочь утверждающим в процессе принятия решения. Голоса утверждения. Когда поле «Группа утверждения» остаётся пустым, то инициатор утверждения может добавить определённых персон для утверждения. Когда рабочая группа выбирается в качестве группы утверждения – все члены данной группы отображаются в списке утверждающих. На данном этапе инициатор может удалить одного или нескольких членов рабочей группы из списка, 33 например, если они не могут провести утверждение до окончания крайних сроков, отведённых для утверждения. При удалении значения поля «Группа утверждения», список утверждающих остаётся без изменений. Когда добавляется другая группа в поле «Группа утверждения», то участники данной рабочей группы добавляются к существующему списку утверждающих. Общее количество утверждающих персон не ограничено. Голоса утверждения. Информация, относящаяся к утверждениям действий специалистов, может быть просмотрена в данном поле. Окно просмотра содержит имя утверждающего и решение. Если специалист отклонил действие – должна отображаться причина. Результат. Данное поле отображает результат утверждения (голосования). Роли утверждающих. Ответственность ваших специалистов основана на областях их экспертизы. Для наилучшего использования их знаний, а также улучшения производительности центра технической поддержки, должны быть определены несколько ролей. Роли утверждающих могут оказать помощь в эффективной разработке системы утверждений. Для ввода в действие системы утверждений, вы должны обозначить работникам следующие роли в вашей компании: Инициатор утверждения. Действие, требующее утверждения должно быть идентифицировано. В процессе принимают участие специалисты, работники центра обслуживания, менеджеры изменений, менеджеры проблем и многие другие, кто авторизован на подобные действия в вашей организации. Активатор утверждения. Изменяет статус листа утверждения с «Неактивный» на «Активный», что является важным в процессе проведения утверждения. Активатором утверждения может быть и инициатор утверждения или кто-нибудь, кто уполномочен в вашей компании решать вопросы предлагаемых утверждений до начала процесса утверждения. Утверждающий. Специалист, указанный в списке утверждения инициатором утверждения или активатором утверждения для проведения процесса утверждения. Специалисты могут быть извещены автоматически, если действия требуют их 34 утверждения. Утверждающие могут быть как отдельными персонами, так и персонами, входящими в определённые рабочие группы. Контролёр утверждения. Для гарантии, что решения по вопросам принимаются в заданные сроки, роль, аналогичная роли менеджера изменений, должна быть принята для контроля статуса листа утверждений. Если лист утверждений не заполнен до окончания максимальных сроков утверждения, то контролёр утверждения может быть уполномочен утвердить или отклонить предлагаемые действия. Пример утверждения проводимого изменения. Пол Адамс, менеджер изменений компании Инвеншн Инк., получает запрос на утверждение изменения, предлагаемого менеджером изменений. Изменение заключается в добавлении дополнительных центральных процессоров в HTTP-сервер. Он инициирует процесс утверждения. Инициация утверждения включает в себя определение утверждающих, определение максимальных сроков утверждения, и политику утверждения (минимальное количество положительных утверждений, которое должно провести изменение). С этой целью добавлено 3 утверждающих и минимум 2 утверждающих должны утвердить изменение. Зарегистрировав себя как инициатора утверждения, Пол теперь может активировать процесс утверждения. 35 Как только процесс утверждения переходит в состояние «Активный», система центра обслуживания запрещает изменение параметров процесса утверждения. Система центра обслуживания рассылает каждому из участников уведомление по электронной почте про необходимость проведения утверждения. На данном этапе результат утверждения принимает статус «Проведение…». 36 Как только второй утверждающий принимает изменение – система центра обслуживания автоматически переводит состояние результата утверждение в «Утверждено» и статус процесса утверждения переводится в «Проведено», указывающий, что процесс утверждения окончен. После того, как изменение утверждено, оно может быть спланировано уже на более детальном уровне. 37 Управление работами. Данная глава производит обзор возможностей системы центра обслуживания, которые помогут пользователям управлять их работами. Сервис сегодня. Представление данных «Сервис сегодня» даёт всеобъемлющее представление элементов, назначенных пользователю, который подключен к системе центра обслуживания. «Сервис сегодня» отображает все обращения, инциденты, наряды, проблемы, и изменения, ответственным за которые назначен текущий пользователь. Представление «Сервис сегодня» может быть создано и изменено, как и любой другой элемент системы. Наряды. Обращения, инциденты, проблемы и изменения часто приводят к необходимости проведения большого объёма работ. Наряды позволяют пользователям системы центра обслуживания планировать, назначать и закрывать проведение текущих работ. Наряд может быть связан как с элементом, по которому требуется проведение работ (обращение, инцидент и т.п.), так и создан независимо от какихлибо элементов. Все работы, зарегистрированные с помощью нарядов, имеют заданный приоритет и отображаемый прогресс выполнения работ в статусе наряда. Детали, относящиеся к планируемой стоимости, и максимально допустимое время для завершения задачи может быть указано в наряде. Оценка времени, которое рабочая группа может потратить на проведение работ, указывается в графе оценки планируемого времени. Персона, которая создаёт наряд, указывает в нём крайние сроки исполнения до завершения, а также ограничивать максимально допустимое время проведения самих работ. В процессе работы с нарядом, наряд может обновляться информацией, относящейся к фактической дате и времени завершения, и времени фактически потраченному над элементом, или какие-либо дополнительные стоимости, связанные с работой, или изменение объёмов проводимых работ… Вы можете наблюдать состояния каждого из нарядов и вносить коррективы в расписание работ при необходимости. Наряды предоставляют аудит закрытых нарядов или нарядов, находящихся в работе. Ответственность, при закрытии нарядов, может изменяться. Если персона, назначенная на выполнение работ в наряде не в состоянии выполнить работы по каким-либо причинам, наряд может быть переназначен другому специалисту или персоне. Система центра обслуживания автоматически создаёт записи аудита при изменении состояния наряда. В записях аудита содержится информация, например, кто и когда провёл изменение наряда. Просматривая записи аудита, пользователи систему центра обслуживания могут определить, когда был завершён наряд, 38 просрочен ли он или что работы не проводились. Вы также можете дописывать произвольную информацию к записям аудита, которая может помочь уточнить информацию по нарядам или контролировать временные интервалы этапов проведения наряда. Назначение. Назначение является одной из ключевых возможностей в управлении работами. Назначения позволяют наиболее подходящим персонам становиться ответственными за обработку элемента. Обращения, инциденты, проблемы, проекты и изменения могут быть назначены. Когда наряд назначается рабочей группе, то может быть сразу выполнена оценка планируемого времени, для определения, какая из рабочих групп в состоянии справится с заданным объёмом работ в указанные сроки. Графики работы и календарь праздников, ассоциируемые с рабочими группами, используется для определения окончания выполнения работ. Если рабочая группа не справилась с работами в отведённые крайние сроки (deadline), вы можете произвести повторную калькуляцию с учётом параметров другой рабочей группы. Жизненный цикл и коды состояний. Каждый элемент в системе центра обслуживания проходит некий жизненный цикл. Коды состояний позволяют указывать, на каком этапе жизненного цикла находится элемент. Сначала элемент создаётся и затем он проходит период, где он может находиться активном в состоянии или состоянии простоя, и отображает, является ли ваша компания ответственной за сопровождения данного элемента или нет. Со временем состояние элемента переходит в закрытое состояние, после чего он может быть перенесён в архив или удалён. Каждый тип элемента имеет собственный жизненный цикл. Например, все обращения, инциденты, проблемы и изменения имеет аналогичный жизненный цикл. Однако жизненные циклы соглашения об уровне обслуживания, или конфигурационной единицы несколько отличаются. Давайте рассмотрим основной жизненный цикл обращения. Когда заказчик связывается с технической поддержкой, создаётся обращение. С этого момента, во многих организациях, элемент рассматривается в состоянии «Новый», и организация является ответственной за предоставление технической поддержки. Если работник центра технической поддержки (1-й линии технической поддержки. Авт.) не в состоянии решить вопрос с обращением этот работник должен перенаправить данное обращение специалисту (2-я линия технической поддержки. Авт.). Специалист может или принять или отклонить данное обращение. Специалист также может запланировать работы или направить обращение другому специалисту. Во время проведения данных работ состояние назначения обращения изменяется, и статус назначения переключается между состоянием «Принят» и «Готовый», в зависимости от действий. Позже, специалист завершает работы и направляет обращение назад в службу технической поддержки. 39 Специалист службы технической поддержки связывается с заказчиком (контактной персоной) обращения для обсуждения решения. С этого момента времени состояние изменяется опять и переходит в «несопровождающее» состояние, пока заказчик проверяет предлагаемое решение. Если заказчик принял предлагаемый вариант, то обращение принимает состояние «Закрыт» и работы по данному обращению прекращаются. Обращение затем может быть использовано для аналитики, например, генерации отчёта по соблюдению соглашения об уровне обслуживания или может стать частью общей базы знаний. С этого момента обращение находится в состоянии «Закрыто». В дальнейшем обращение может быть удалено или перемещено в архив с целью освобождения места для новых обращений. Жизненный цикл обращения, в основном, является линейным. Обращение создаётся, обрабатывается и, наконец, удаляется или переносится в архив. Некоторые этапы, такие, как направление специалисту, планирование и работы по обращению, могут повторяться более одного раза. Жизненный цикл обращения становится более похож на круговой, если заказчик отклоняет предлагаемое решение и работа над обращением начинаются с начала. Текущая позиция элемента в жизненном цикле выражается в кодах состояния. Если рассмотреть на примере договора обслуживания, кодами используемых состояний являются: Новый. Подготовка. Действующий. Аннулирован. Как видите, коды состояний только отображают шаги жизненного цикла, которые являются важными в системе центра обслуживания. Говоря другими словами, коды состояний являются схематическим отображением жизненного цикла элемента в реальной жизни. В зависимости от того, каким образом элементы обрабатываются в Вашей компании и на основе того, что для компании является важным, элементы системы центра обслуживания могут иметь различное количество кодов состояний. В дальнейшем данные коды состояний должны быть связаны с состояниями. Вы можете создавать представления и отчёты, основанные на состоянии элементов. Например, может быть определено представление, отображающее все открытые обращения, которые не обработаны, хотя работы по ним должны проводиться. Это может быть элемент с состоянием простоя, хотя находится в «ответственном» состоянии. Каталоги и категории. Каталоги и категории являются вспомогательными элементами для проведения обработки информации системы центра обслуживания. По существу, оба группируют элементы, но несколько различными путями, о чём будет рассказано немного ниже. 40 Каталоги. Помещая элементы в каталоги, пользователи могут разделить элементы, относящиеся к разным группам заказчиков, типов бизнеса или любым предопределённым критериям. Например, ваша компания может работать с различными заказчиками. Эти заказчики могут являться различными департаментами одной компании или они могут быть разными компаниями. В вашей компании персонал может быть выделен для работы с конкретной группой заказчиков. Разделяя элементы по каталогам, каждый пользователь системы центра обслуживания может сфокусироваться на потребностях элементов определённого каталога. Использование каталогов лучше проиллюстрировать на примере центра технической поддержки. В большом центре технической поддержки, заказчики получают определённый телефонный номер, который является уникальным для их компании или пользователей определённого типа. Обращения одного заказчика или типа бизнеса теперь проходят через одного работника или одну рабочую группу центра технической поддержки. Работник центра технической поддержки, знает всё о заказчике, знает общие проблемы данного каталога и знает лучших специалистов для данного каталога. Если данный работник должен работать только с этим каталогом, то его работа ускоряется. Система центра обслуживания может получать только те данные, которые относятся к определённому каталогу, используя для этих целей фильтры представлений. Не только работники центра технической поддержки могут иметь возможность использования каталогов, но и специалисты могут быть организованы для работы только по определённым группам заказчиков и могут получить преимущество при использовании каталогов. Используя возможность именования каталогов можно ещё больше ограничить доступ пользователей. Для этого предоставляются средства ограничения доступа пользователя к каталогам для каждого элемента системы центра обслуживания. Производимый для пользователей системы центра обслуживания эффект, от данной возможности, состоит в том, что когда пользователи производят поиск элементов или отображают данные, они могут видеть только те элементы каталогов, к которым у них есть доступ. Например, пользователь с определённой ролью, может иметь возможность изменить обращения для определённой компании, но наряды только просматривать. Пользователи могут иметь возможность создавать, редактировать, и удалять только те элементы каталогов, на которые имеют права. Категории. Расположение элементов в определённых категориях позволит производить обработку элементов наиболее эффективным способом. Например, возможно покажется важным производить отличие обращений с претензиями и запросов предоставления информации. Вы можете определить представление, отображающее только определённую категорию информации. 41 Каждый тип элемента может иметь собственную уникальную структуру категорий. Структура категорий может быть очень сложной. Конфигурационные единицы, например, могут иметь многоуровневую структуру категорий. Каждый уровень структуры категоризирует элемент более детально. Различные уровни структуры категорий могут быть отображены в иерархической форме, которая наиболее удачно отображает иерархическую структуру. Наивысшая категория является наиболее общей, низшая является наиболее специфичной. В основном, элементы размещаются в наиболее детализированной категории, максимально подходящей для данного элемента. Категоризация элементов, также приводит к разрешению или запрету использования добавляемых (origin. custom) полей. Все добавляемые поля, определённые для данного типа элементов, отображаются в форме элемента. Однако, некоторые добавленные поля могут оказаться неподходящими для определённой категории. Например, могут быть определены и добавлены два поля для конфигурационных единиц: одно поле отображает IP-адрес сетевой платы, другое формат бумаги принтера. Добавленное поле IP-адреса применимо только при использовании категории «Сеть» для конфигурационной единицы. Если вы выберете категорию «Сеть», поле, отображающее размер бумаги, будет запрещено для использования. И наоборот, для принтеров поле «Размер бумаги» является допустимым. Записи аудита (origin. History lines). Записи аудита выступают в роли журнала записей для контроля изменений элемента. Пользователи системы центра обслуживания могут добавлять комментарии, которые могут оказать помощь в работе с элементом. Записи аудита, также, могут быть использованы для контроля времени работы над элементом. В дальнейшем, например, данная информация может быть использована в процессе планирования проектов или контроля времени обработки запросов заказчика. Элементы в системе центра обслуживания могут изменяться каждый день. Некоторые изменения являются небольшими и незначительными, но часто возникает вопрос контроля производимых изменений. Например, информация о персоне, закрывшей обращение пользователя, может являться важной. Записи аудита в системе центра обслуживания предоставляют возможность для учёта данной информации. Контроль проводимых изменений также называется аудитом. Политики аудита определяют, какого типа информация будет вноситься в записи аудита. Записи аудита могут быть сгенерированы системой или пользователем. Сгенерированные системой. Сгенерированные записи создаются системой центра обслуживания. Например, когда элемент 42 изменяется, генерируется запись аудита, отображающее время проведения изменения, кто провёл изменение, и что было изменено. Записи, сгенерированные системой, не могут быть изменены пользователями системы центра обслуживания, но к ним может быть добавлена дополнительная информация. Не все действия, производимые над элементом, имеет смысл контролировать. Администраторы системы центра обслуживания регулируют объём и детализацию информации аудита системы. Сгенерированные пользователем. Записи аудита, вносимые пользователями, могут являться превосходным средством передачи информации, которая может быть полезна при работе над элементом. Записи, созданные пользователем, могут содержать задаваемые вопросы, переписку электронной почты, содержать обобщённую информацию телефонных переговоров или ссылки, которые помогут в работе над элементом. Пользовательские записи также показывают, кто и когда создавал данные записи. Пользователи могут изменять тему и информацию пользовательских записей аудита. 43 Интернациональная система центра обслуживания. Для многих компаний обслуживания ИТ, бизнес располагается по всему миру. Заказчики и коллеги могут находиться по всему континенту или, даже, по всему миру, работая в различных часовых поясах. Используя систему центра обслуживания и современные технологии коммуникаций, организации поддержки ИТ могут решать каждодневные проблемы в глобальной инфраструктуре ИТ. Часовые пояса. Максимальное время решения (deadline) – дата и время, в течение которого события должны быть решены, согласно локальному времени пользователя. Заказчики хотят знать назначенную дату и время, определённую их локальным временем, в то время как коллеги хотят видеть данную информацию относительно своей временной зоны. Пользователи системы центра обслуживания могут переключаться между отображением собственной локальной даты и времени и временем коллег и заказчиков. Таким образом, при общении с заказчиком, пользователи могут договариваться о дате и времени часового пояса заказчика, одновременно составляя расписание в своей временной зоне или временной зоне коллег. Система центра обслуживания также поддерживает переход на летнее и зимнее время. Система центра обслуживания может оказывать вам поддержку во всём мире, так как время хранится в формате Всеобщего скоординированного времени (UTC). UTC рассматривается как стандартное время: всё остальное время и временные зоны ведут отсчёт от UTC. Например, если вы живёте и работаете в Миннеаполисе (MN, USA), то вы находитесь во временной зоне центрального стандартного времени (CST). Временная зона CST находится на 6 часов раньше, чем временная зона UTC. Таким образом, для подсчёта времени в Миннеаполисе, необходимо вычесть 6 часов из хранимого времени. Для подсчёта локального времени в Токио (Япония), необходимо добавить 9 часов к хранимому времени. Локализация. Для проведения локализации, вы можете перевести и адаптировать большинство текстовых сообщений системы центра обслуживания, для использования с локальным языком, или для использования с глоссарием терминологии ИТ в вашей организации. Система центра обслуживания использует UTF-8 кодировку и в соответствии со стандартами Microsoft Windows, любой используемый язык в операционной системе может быть установлен в системе центра обслуживания. 44 Гибкость системы центра обслуживания. Система центра обслуживания предоставляет гибкость в конфигурации и адаптации. Системные администраторы могут использовать консоль администратора для конфигурирования и адаптации централизованно для всех пользователей, в то время как отдельные пользователи могут выбирать параметры и проводить личную адаптацию системы, которая не касается других пользователей. Консоль администратора. Консоль администратора позволяет системным администраторам применять параметры, вести разработку форм, представлений, графиков и полей распределения по пользователям с корректной авторизацией: Администраторы могут тонко настроить параметры системы центра обслуживания, в соответствии со специфическими требованиями инфраструктуры ИТ. Параметры могут изменяться одновременно с изменениями политики предоставления услуг. Администраторы могут создавать и редактировать следующие определения в консоли администратора: Роли и учётные записи. Учётные записи предоставляют пользователям доступ к системе центра обслуживания. Роли определяют доступный функционал системы центра обслуживания, которым будет разрешено воспользоваться пользователям. Роли определяют права доступа к элементам, полям, представлениям, формам, шаблонам и действиям. Роли могут предоставлять детализированный доступ к элементам, 45 используя настройки параметров каталога и состояний элементов. Роли также определяют, может ли пользователь адаптировать инструментальную панель под собственные нужды, может ли создавать ссылки, может ли создавать или редактировать представления и т.п. Бизнес-логика. o Правила. Администраторы могут создавать правила, которые позволяют запускать различные комбинации действий в системе центра обслуживания. Два типа правил могут быть созданы для этих целей: правила БД, и правила пользовательского интерфейса. Каждое правило является триггером действий при создании, удалении, редактировании в базе данных системы центра обслуживания или в пользовательском интерфейсе. o Действия. Быстрые действия являются ссылками для дополнительных задач, выполняемых внешними программами. Например, использование Microsoft Excel для генерации отчёта обо всех используемых КЕ. Системные действия являются ссылками на функциональные возможности, разработанные программистами системы центра обслуживания. Системные действия создаются для задач, которые могут быть слишком сложными для ручного выполнения. Системные действия, включая анкетирование, могут быть использованы персоналом технической поддержки для задания стандартных вопросов, когда заказчики запрашивают определённые услуги, или помощник генерации КЕ, который может быть использован менеджерами конфигураций для выполнения пакетных заданий. Действия представлений являются ссылками на представления, которые отображают информацию, основанную на текущем контексте. Представления данных. Администраторы могут создавать системные представления и контролировать доступ пользователей к ним. Если пользователи имеют необходимые полномочия, они могут создавать собственные представления или редактировать существующие. Модифицированные системные представления или адаптированные представления доступны только их создателям. Формы. Используя технологию перенести-и-оставить (drug-anddrop), администраторы могут легко разрабатывать формы. Поля. Администраторы могут добавлять, удалять или редактировать необходимые поля в жизненном цикле конфигурационной единицы. Например, может потребоваться поле авторизации для запросов на изменения. Шаблоны данных. В дополнение к шаблонам, предоставляемым с демо-версией БД, вы можете создавать собственные шаблоны с учётом потребностей текущей инфраструктуры ИТ. Например, вы можете задать шаблон для регистрации нового сотрудника. Шаблоны, также, используются в процессе импорта данных в систему центра обслуживания из внешних источников. Подробности смотрите в HP Open View: Data Exchange Administrator Guide. 46 Категории шаблонов данных. Вы можете создавать категории шаблонов и назначать им шаблоны. Это позволяет вам группировать и структурировать шаблоны. Одна структура категории шаблонов распределяется между всеми типами элементов. Один из подходов к использованию категорий шаблонов состоит в создании категории для каждого типа элемента, и затем создавать подкатегории некоторое количество подкатегорий ниже этого уровня. Например, категория конфигурационных единиц может содержать отдельные подкатегории для каждого типа конфигурационной единицы (таких как монитор, жёсткий диск и т.п.). Основные параметры. Администраторы могут редактировать, обновлять или удалять любые из параметров. Например, вы можете добавить дополнительный номер телефона пользователя в качестве критерия поиска. Консоль системы центра обслуживания. Консоль системы центра обслуживания позволяет пользователям адаптировать выводимую им информацию и применять персональные предпочтения для параметров системы центра обслуживания. Информация, отображаемая в представлениях данных, может быть сгруппирована и отсортирована по определённым критериям без необходимости тратить время на изучение какого-либо языка программирования. Параметры, применяемые пользователем, включают в себя следующее: Язык, используемого интерфейса пользователя. Метки, меню, сообщения т.д. Обязательные поля форм. Форматы отображения даты, времени, валют и чисел. … 47 Введение в сервисные страницы. Сервисные страницы являются расширением системы центра обслуживания. Пользователи получают возможность не только контактировать со службой технической поддержки, но и получают доступ к данным. Сервисные страницы имеют два типа пользователя: инженеры поддержки, которые и так имеют доступ к системе центра обслуживания и сервисных пользователей. Сервисные пользователи могут выполнять следующие задачи: Осуществлять поиск известных решений. Читать часто задаваемые вопросы (ЧаВо). Вносить и контролировать запросы на обслуживание. Инженеры технической поддержки могут использовать сервисные страницы для выполнения следующих действий: Создавать обращения. Создавать инциденты. Обзор обращений. Обзор инцидентов. Обзор проблем. Обзор изменений. Обзор нарядов. Инженеры поддержки могут редактировать или просматривать записи, при использовании одного или нескольких возможностей обзора. Системные администраторы могут определять формат отображения, также как и задавать используемые шаблоны при создании элементов. В процессе настройки формата отображения 48 представлений системные администраторы определяют вид для краткого и полного списка элементов. Доступ к сервисным страницам. Доступ к сервисным страницам может быть осуществлён с помощью обычного WEB-обозревателя, например Netscape®, Mozilla или Microsoft Internet Explorer®. Клиенты осуществляют соединение по сети с HTTP-сервером. HTTP-сервер может быть размещён вместе с сервером приложений, а может, например, для балансировки нагрузки, быть размещённым где угодно. Ваш WEB-обозреватель соединяется с HTTP-сервером через сеть. 49 WEB-Обозреватель Сеть HTTP-сервер Сеть БД центра обслуживания Утверждение через WEB. В соответствии со статусом изменения элемента, такого как обращение или изменение, возможно потребуется проведение утверждения для одного или более людей. С системой центра обслуживания, доступна WEB-страница, где утверждающие могут утвердить запрашиваемое действие. WEB-страница утверждений не является частью сервисных страниц и может быть доступна только по определённому URL, высылаемому сообщением электронной почты утверждающим. 50 4. Основные задачи. Эта глава рассматривает основные задачи, выполняемые пользователями системы центра обслуживания. Просмотр информации. Система центра обслуживания предоставляет множество вариантов просмотра информации. Вы можете выбирать содержание информации, которая будет отображаться, например, все открытые обращения, и можете указать формат, в котором необходимо отобразить данные. Основными форматами отображения являются: Формат таблицы. Формат графиков. Формат обозревателя. Формат карт. Формат иерархии (дерева). Формат проекта. Использование формата таблицы. Табличный формат является основным форматом представления данных. Табличное отображение обращений, например, отображает каждое обращение в отдельной строке со значениями специфических атрибутов в столбцах. Отображаемая информация может быть упорядочена по определённым критериям, например, по времени крайнего срока для предоставления решения (deadline). 51 Информацию в табличном представлении можно группировать по определённым критериям. Например, вы можете сгруппировать обращения в соответствии с их статусом. Формат графиков. Графики предоставляют графическое представление хранимой информации. Графики группируют элементы и отображают абсолютный или относительный размер групп. Графики могут отображать информацию в широком диапазоне различных форматов. Формат графиков является лёгким для чтения и вывода на печать. Графики также представляют лёгкий доступ к элементам. Это выполняется двойным (double-click) нажатием на часть графика, вызывающим табличное представление, карточное или другой графический формат для отображения выбранных элементов, относящихся к этой части графика. Графическое представление может быть адаптировано. Например, вы можете выбрать цветовую гамму графика, тип отображаемого графика (круговая диаграмма, корреляционная диаграмма, гистограммы), и в случае 3-х мерных графиков, угол, под которым он будет изображён. Группируются элементы графика по оси Х (абсцисс) и отображают количество в каждой группе по оси Y (ординат). В круговых диаграммах ось абсцисс определяет отдельные сегменты окружности, а ось ординат определяет размер каждого сегмента. 52 Вместо отображения количества по оси ординат, вы можете выбрать отображение планируемой или реальной стоимости или длительности, или можете отобразить любое из подсчитываемых полей: Общее суммирование стоимости или длительности. Средняя стоимость или длительность. Минимальная стоимость или длительность. Максимальная стоимость или длительность. Вы можете использовать второе значение по оси ординат. Это позволяет вам проводить сравнение двух различных значений, таких как планируемая и фактическая стоимость. В качестве альтернативы, значения оси ординат могут быть разложены по сериям групп компонентов. Например, вместо отображения общего количества обращений по оси ординат, к дате регистрации по оси абсцисс, вы можете отобразить обращения, как серии, сгруппированные по коду влияния. Вы можете копировать графики во внешние приложения, такие как Microsoft Word или PowerPoint. Формат обозревателя. Формат обозревателя состоит из панели навигации, основной панели и из одной или нескольких листьевых панелей, как изображено на рисунке. Базовая панель отображает основную информацию, которую вы просматриваете. Листевые панели отображают детализированную информацию, которая относится к элементам, выбранным в базовой панели. Панель навигации предоставляет средство поиска основной информации. Для поиска информации в панели навигации необходимо: 1. Перейти в навигационной панели к элементу и выбрать его. 2. Выбрать его в базовой панели. 3. Листьевая панель отобразит подробную информацию о выбранном элементе. 53 Например, на рисунке выше, вы используете навигационную панель размещения, для поиска конфигурационных единиц в определённом месте. Найдя интересующую вас конфигурационную единицу и выбрав её в базовой панели, вы можете увидеть все зарегистрированные обращения по данной конфигурационной единице в листьевой панели обращений. Формат карт. Формат карт отображает информацию в виде карты индекса. Каждый элемент отображается в виде отдельной карты. Каждая линия карты отображает детали элемента. Вы можете использовать карточный формат для быстрого поиска или просмотра элементов, которые могут быть представлены в алфавитном порядке, такие как информация о служащих. Формат иерархии (дерева). Формат иерархии отображает информацию аналогично навигационной панели формата обозревателя. Формат иерархии удобен для отображения структурированной информации, такой как, например, структура организации. 54 Формат проекта. Формат проекта предоставляет обзор скоординированных действий. Вы можете отображать информацию о нарядах, которые сгруппированы вместе в элемент Изменение, или изменения, которые сгруппированы в проект. Формат проекта отображает список действий и общий прогресс в графическом формате диаграммами GANTT или PERT. 55 56 Использование меню действий. Меню «Действия» предоставляет ссылки на задачи, относящиеся к элементам системы центра обслуживания. Следующий рисунок изображает пример меню «Действия» для обращений. Меню действия содержит три типа действий: Быстрое действие. Быстрые действия запускают внешние программы. Вызов внешней программы может сопровождаться передачей информации выбранного элемента в текущем представлении. Например, Microsoft Word может быть открыт для создания текстового файла, с использованием идентификатора текущего открытого обращения в качестве имени файла. Действия обзора. Действия обзора открывают табличные представления других элементов. Информация открываемых табличных представлений может быть отфильтрована, для отображения информации, относящейся к текущему выбранному или открытому элементу. Системные действия. Системные действия определяются разработчиками системы центра обслуживания, для выполнения сложных задач, которые трудно выполнить другим путём. Например, создание обращений субподрядчику является системным действием. Использование расширенного поиска. С использованием расширенного поиска, вы можете указать сложные критерии поиска хранимых в системе центра обслуживания элементов. На следующем рисунке изображён диалог расширенного поиска, готовый для ввода критериев поиска обращений. 57 Первая закладка страницы диалога расширенного поиска содержит поля, которые позволяют вам осуществлять общий поиск. Например, вы можете найти все обращения определённого инициатора. Закладка страницы «Расширенный выбор» предоставляют критерии поиска ассоциированные с пользователем системы центра обслуживания, осуществляющим поиск. Например, пользователь системы центра обслуживания может найти все запросы изменений, для которых он является утверждающим. Закладка страницы «Расширенный» содержит наиболее сложные критерии поиска. Например, вы можете найти все обращения с приоритетом «наивысший» или «высокий», время разрешения которых превысило крайние сроки предоставления решения (deadline) сегодня. 58 Пример. Поиск похожих обращений. В процессе регистрации обращения, согласно которому инициатор описывает низкую производительность сервера опроса в качестве симптома, Иван, являющийся администратором АСКУЭ, решает ускорить разрешение инцидента поиском аналогичных обращений. Для начала он должен найти обращение. При нахождении курсора в поле «Информация», он нажимает «F2», для отображения диалогового окна расширенного поиска, в которое система центра обслуживания копирует содержимое поля «Информация»: 59 Иван затем выбирает фразу «Низкая производительность сервера опроса» (другие обращения могут использовать отличные слова от «Низкая», для описания характеристики производительности.) и нажимает кнопку «Добавить». Фраза добавляет в поле значения: Иван нажимает «Добавить в список», для добавления условия в список критериев поиска, затем наживает «Найти сейчас» для запуска процесса поиска. Одно из соответствующих обращений найдено, и это отображается в нижней части диалогового окна поиска. Ну и, наконец, Иван выбирает полученную строку и наживает «ОК». Содержание полей копируется из исходной строки и вставляется в форму нового обращения. 60 Заметка. Настройки в Консоли Администратора определяют, какие из полей подлежат копированию. Иван может теперь редактировать любое из полей по необходимости. 61 5. Задачи пользователя. Данная глава описывает процесс создания отчётности по обращениям и контроля их статуса. Пример. Регистрация обращения. Иван Иванов, работник вашей компании, испытывает затруднения с модулем «Энергия-Альфа. Администратор». Он не может установить соединение с базой данных. Он обращается к базе знаний системы центра обслуживания департамента обслуживания, к разделам часто задаваемых вопросов (ЧаВо), но он всё равно не в состоянии решить проблему. Каково решение? Иван может контактировать со службой технической поддержки несколькими способами для получения помощи. Он может позвонить по телефону, отправить факс или сообщение электронной почты. Иван выбрал обращение с использованием сервисных страниц. Используя сервисные страницы, он немедленно получает номер своего обращения и затем может отслеживать по нему прогресс работы по решению его обращения, используя свой WEB-обозреватель. Администрирование обращений. Одной из главнейших целей пользователей сервисов является получение быстрого решения их проблем. Пользователи сервисов могут быстро создавать обращения несколькими возможными путями: Электронная почта. WEB-обозреватель (сервисные страницы). Телефон (для автоматизации требуется доп. интеграция). Факс (для автоматизации требуется доп. интеграция). Регистрация обращений. Одна из основных функций службы технической поддержки состоит в разрешении запросов пользователей на оказание технической поддержки. Некий начальный объём информации должен быть предоставлен персоналу технической поддержки, прежде чем техническая поддержка может начать эффективно обрабатывать запрос. В соответствии с источником получения обращения, можно попробовать получить от инициатора обращения основную информацию, такую как: Фамилия, имя, отчество контактной персоны. Затронутая проблемой конфигурационная единица. Насколько это позволяет, полное описание проблемы. Масштабы отказа (сколько затронуто людей, департаментов, организаций и пр.). 62 Использование сервисных страниц. Используя WEB-обозреватель, заказчик может регистрировать обращения и обращаться к разделу часто задаваемых вопросов (ЧаВо). Заказчики при использовании сервисных страниц, также могут видеть предлагаемое им решение для устранения возникших проблем. 63 6. Задачи персонала технической поддержки. Данная глава описывает функции и меню, которые может использовать оператор технической поддержки, для контроля обращений. Также предоставлен примерный сценарий обработки обращения. Пример. Работа оператора технической поддержки. Ваш отдел кадров принял на работу нового сотрудника, Ивана Иванова, и инициировал запрос по электронной почте о найме нового сотрудника. Вы открываете консоль центра обслуживания и создаёте новое обращение с использованием шаблона «Новый сотрудник». Шаблон «Новый сотрудник» автоматически генерирует необходимое количество нарядов, используя предопределённые шаблоны. Наряды автоматически направляются соответствующим департаментам, и включают в себя работы, такие как установка мебели и компьютера, создание новой учётной записи и установку необходимого ПО. Обзор задач оператора технической поддержки. Основной задачей оператора технической поддержки является предоставление решений возникающих проблем как можно в более сжатые сроки. Оператор технической поддержки является первой линией поддержки при оказании услуг заказчику. Вы должны распределять задачи принятия обращений и выдачи решений. Если вы не можете предоставить решение, например, при отсутствии необходимого уровня компетенции, – вы должны перенаправить запрос специалистам второй линии технической поддержки. Как оператор технической поддержки, вы используете в работе ряд определённых представлений (напр. для мониторинга состояния конфигурационной единицы) и набор утилит, определённых администратором системы центра обслуживания. После запуска консоли системы центра обслуживания, оператор может увидеть примерно следующее: 64 Администрирование обращений. Обращения являются зарегистрированными запросами от заказчиков для выполнения одной из задач, например: Решить инцидент. Провести определённые изменения сервиса. Предоставить информацию. Регистрация обращений. Для регистрации обращений используется форма обращений. 65 Ваше руководство может рассмотреть вопрос использования поставляемых с системой шаблонов или определить новые типы шаблонов для тех или иных задач. При регистрации обращения, производится сбор информации, которая может быть очень полезной в процессе решения проблемы. Вводимая вами информация может использоваться не только специалистами по решению проблем, но и менеджерами изменений, менеджерами проблем, менеджерами конфигураций, руководством департамента и компании. Анкетирование – один из подходящих способов получения информации от заявителя. Следующие поля являются всегда обязательными: Описание. Наиболее точное описание произошедшего события должно быть зафиксировано. Согласно этому описанию, специалисты могут начинать решать проблему. Статус. При нажатии стрелки вниз в поле статуса, выводится список возможных статусов для нового обращения. Вы не можете ввести в данное поле произвольный текст, оно может заполняться только одним из определённых значений. Данный список поддерживается администратором системы центра обслуживания. Например, вы можете обозначить зарегистрированное обращение статусом «Зарегистрировано». 66 Заметка. Другие поля могут также быть обязательными для заполнения. Это определяется совместно администратором центра обслуживания, руководством подразделения и другими заинтересованными лицами. По умолчанию обязательные поля выделены полужирным шрифтом. Вы можете изменить формат отображения обязательных полей с целью облегчения их поиска. Проведение анкетирования. Анкеты создаются вашим администратором. Вы можете выбрать анкету при регистрации обращений. Каждая анкета содержит перечень стандартных вопросов, которые необходимо задать инициатору. Когда анкета заполнена – информация автоматически вносится в поле информации обращения, откуда её могут уже получить специалисты. Просмотр обращений. Обращения можно получить и просмотреть несколькими различными способами в консоли системы центра обслуживания. Вы можете просмотреть обращения в представлениях «Сервис сегодня» или «Обращения». Также, вы можете видеть обращения следующими способами: Выбрать действие обзора доступное в меню «Действия». Например, при просмотре конфигурационных единиц, вы можете выбрать действие обзора, для просмотра всех обращений текущей конфигурационной единицы. Воспользовавшись расширенным поиском. Обновление обращений. Когда вы просматриваете обращения, вы можете также обновлять записи дополнительной информацией. Примеры, при которых требуется обновление информации: Назначение специалистов. Изменение контактной информации. Запись действий по решению проблемы. Изменение статуса обращения. Если вы не можете предоставить решение проблемы, вы должны перенаправить обращение специалисту следующей линии технической поддержки. Создание обращений субподрядчику. Если анализ проблемы показывает, что необходимо обращение к провайдеру услуг или производителю оборудования для решения корневых причин возникновения проблемы, вы можете создать обращение субподрядчику. Система центра обслуживания автоматически копирует информацию события и регистрирует вас в качестве инициатора запроса. Закрытие обращения. В случае положительного решения проблемы и получения подтверждения от заказчика об успешном решении проблемы, 67 обращение может быть закрыто. Закрытие производится установкой соответствующего статуса обращению. Пример. Создание обращения. Иван Иванов, являющийся оператором центра технической поддержки, принимает телефонное обращение от заказчика об оказании технической поддержки. Иван создаёт новое обращение используя форму и шаблон по умолчанию: Иван должен, в первую очередь, идентифицировать заказчика. Это помогает в идентификации того, что организация обратившегося заказчика является действующим клиентом компании. Обратившийся идентифицирует себя как Василий Васильев. Иван вносит несколько первых символов фамилии и нажимает кнопку <TAB>. Система центра обслуживания находит несколько имён, которые удовлетворяют критерию поиска, и отображает их в диалоговом окне быстрого поиска. 68 После идентификации своей организации как «Ы и компания», Иван выбирает корректное имя обратившегося из предложенного списка и нажимает «ОК». Система центра обслуживания находит только один сервис, для которого обратившийся и его организация являются получателями, в соответствии с действующим договором обслуживания, и все соответствующие подробности автоматически вставляются в соответствующие поля, вместе с уровнем обслуживания, прописанным в договоре. Так как SLA действует только в рамках предоставления услуг по обслуживанию АИИС КУЭ «Ы и компания», система указывает группу обслуживания по умолчанию (группа администраторов АИИС КУЭ), система центра обслуживания автоматически назначает данную группу для обработки обращения. 69 Иван теперь запрашивает подробную информацию об обращении. Он вводит краткую информацию в поле «Информация» и подробное описание в поле «Описание». 70 После обсуждения с обратившимся о границах проблемы и влияния проблемы на сервис, Иван назначает высокий код влияния обращению. Влияние-приоритет отображение, определённое уровнем обслуживания (24x7), присваивает наивысший код приоритета, который автоматически устанавливает максимальное время разрешения проблемы в 1 час. Система центра обслуживания автоматически устанавливает крайние сроки предоставления решения, с учётом расписания обслуживания и часовых поясов. 71 Иван знает, что один из стандартных ответов, на подобного рода обращения – перезапуск сервера. Иван добавляет наряд к обращению, для выполнения данного действия и назначает его соответствующим рабочим группам специалистов. 72 Ну и, наконец, обращение сохраняется и форма закрывается. С этого момента, данное обращение появляется в представлении «Сервис сегодня» для специалистов, которые назначены для обработки данного обращения. Зависимости процессов системы центра обслуживания. Отмечая любые элементы системы центра обслуживания (например, проблемы и изменения), к которым относится обращение, вы можете оказать помощь специалистам по вопросам решения возникающих проблем. Когда вы связываете обращение с другим элементом системы центра обслуживания, информация становится взаимосвязанной и специалисты, при поддержке менеджеров проблем или изменений, могут начинать работу. 73 Зависимости ролей системы центра обслуживания. Ваша роль, как оператора системы центра обслуживания, состоит во взаимодействии со следующими ролями: Специалисты. Обращения, которые вы не можете разрешить самостоятельно, передаются профильным группам специалистов. Менеджеры конфигураций. Менеджер конфигураций ведёт учёт и классификацию активов инфраструктуры ИТ. Менеджер конфигураций также определяет коды поиска конфигурационных единиц, по которым создаются обращения. Менеджер проблем. Регистрируемые вами обращения анализируются на предмет повторений менеджерами проблем. Менеджер изменений. Регистрируемые вами обращения анализируются на предмет идентификации изменений, необходимых для реактивного и проактивного решения проблем. Также, может быть необходимость уведомления заказчиков о планируемых изменениях конфигурационных единиц. Менеджер уровня обслуживания. Менеджеры уровня обслуживания определяют уровень обслуживания и сервисы, которые должны быть предоставлены заказчику. Менеджер уровня обслуживания напрямую влияет на количество предоставляемых вами услуг, как первой линии технической поддержки, также и на количество самих специалистов, обрабатывающих обращения. Администратор организаций и персон. Персонал инфраструктуры ИТ и конечные пользователи, вот основные списки форм вашего 74 рабочего поля. Администратор определяет данные, которые будет содержать каждая из конфигурационных единиц: профессионалы, предоставляющие техническую поддержку и реальные владельцы конфигурационных единиц. Ваши задачи, как персоны первого контакта, являются критичными для успешного и максимально выгодного внедрения системы центра обслуживания. Без вашей точной идентификации обращений и согласованных регистрационных данных, специалистам невозможно качественно и эффективно обрабатывать обращения. 75 7. Задачи менеджера конфигураций. Эта глава описывает задачи менеджера конфигураций, а также преимущества использования системы центра обслуживания при выполнении задач. Также описан процесс управления конфигурационными единицами. Администрирование конфигурационных единиц. Конфигурационные единицы являются ключевым элементом системы центра обслуживания. Конфигурационные единицы включают в себя всё, что образует инфраструктуру ИТ, сети, серверы, персональные компьютеры, программное обеспечение и периферия, счётчики, трансформаторы и прочие элементы АИИС КУЭ. Как менеджер конфигураций вы определяете, что является конфигурационной единицей для вашей инфраструктуры ИТ. Конфигурационные единицы поддерживаются на протяжении всего договора обслуживания в базе данных конфигурационных единиц (CMDB). Рисунок ниже отображает консоль CMDB. Группа CMDB в панели ссылок содержит пиктограммы, отображающие информацию по конфигурационным единицам и договорам обслуживания этих КЕ. Категоризация конфигурационных единиц. Насколько детализировано описание вашей инфраструктуры ИТ? Один менеджер конфигураций может, вместе с серверами и персональными 76 компьютерами, рассматривать в качестве конфигурационных единиц компьютерные мыши, цифровые камеры и коврики для мышей, а другой ограничиться рассмотрением только серверов и персональных компьютеров. Заметка. При рассмотрении детализации описания инфраструктуры ИТ, учтите, что согласованное и детализированное представление инфраструктуры ИТ помогает в локализации возникающих проблем. Например, некий сервер не в состоянии запустить программное обеспечение из-за нехватки объёма оперативной памяти, идентификация типа памяти для обновления может оказаться ценной информацией в конфигурационной единице сервера в данном случае. Если оба, сервер и оперативная память, являются отдельными конфигурационными единицами, обновление может быть назначено с минимальными усилиями. Регистрация конфигурационных единиц. Вы можете регистрировать конфигурационные единицы двумя путями: Используя форму новой конфигурационной единицы. Используя помощника генерации конфигурационных единиц. Использование формы новой конфигурационной единицы. Если вам требуется создать небольшое количество конфигурационных единиц или информация о конфигурационных единицах краткая или отсутствует вообще, используйте форму новой конфигурационной единицы: 77 При создании конфигурационной единицы следующие поля являются всегда обязательными: Код поиска. Разрабатывая систему именований, вы помогаете другим пользователям быстро находить определённые конфигурационные единицы. Если ваша компания уже имеет существующую систему именования для конфигурационных единиц, система центра обслуживания позволяет её легко интегрировать. Ваши контактные персоны, пользователи, специалисты и менеджеры инфраструктуры ИТ могут идентифицировать конфигурационные единицы, по тем принципам, с которыми они уже знакомы. Если требование вашей системы именования является в уникальности кодов поиска – система центра обслуживания гарантирует, что данные требования будут соблюдаться. Статус. При нажатии стрелки вниз в поле статуса, вы увидите выпадающий список кодов статуса, которые могут быть применены к конфигурационной единице. Пользователи системы центра обслуживания создающие новые конфигурационные единицы не могут ввести в данное поле произвольный текст. Максимальное количество установок. Показывает максимальное количество допустимых установок неуникальных конфигурационных единиц. Для уникальных конфигурационных 78 единиц, данное значение автоматически устанавливается равным 1. Заметка. Другие поля могут быть также обязательными для заполнения, как определено вашим менеджером инфраструктуры ИТ и администратором системы центра обслуживания. По умолчанию, поля обязательные для заполнения выделены полужирным шрифтом. Вы можете изменить внешний вид полей обязательных для заполнения для их улучшенного отображения. Использование помощника генерации конфигурационных единиц. Если вы должны сгенерировать множество аналогичных или идентичных конфигурационных единиц, используйте генератор конфигурационных единиц. Помощник генерации конфигурационных единиц, предоставляет вам пошаговое руководство по генерации конфигурационных единиц, начиная с указания шаблона генерации, заканчивая генерацией. По окончании процесса генерации КЕ вам предоставляется сводный отчёт о результатах процесса генерации конфигурационных единиц, включая детализированных отчёт по конфигурационным единицам, которые не создались. Просмотр конфигурационных единиц. Просмотр конфигурационных единиц существенно упрощается, если вы создаёте некую систему именования конфигурационных единиц, принятую и согласованную между остальными пользователями системы центра обслуживания. Вы можете редактировать и просматривать конфигурационные единицы несколькими способами из консоли системы центра обслуживания. Вы можете просматривать конфигурационные единицы из представления данных о конфигурационных единицах. Альтернативные способы состоят в следующем: Выбор действия обзора, которое доступно в меню «Действия». Например, при просмотре сервисов вы можете выбрать действие обзора КЕ, которые управляемы выбранным сервисом. Выбор действие обзора в элементе поиска. Например, при регистрации нового обращения, вы можете выбрать действие обзора, для отображения всех КЕ, используемых инициатором. При расширенном поиске. Для дополнительной информации по использованию меню действий, обратитесь к справочной информации системы центра обслуживания. Обновление конфигурационных единиц. При просмотре конфигурационных единиц, вы также можете производить редактирование полей дополнительной информации, в случае, если вам предоставлены такие полномочия в системе центра обслуживания. Примеры ситуаций, в которых необходимо обновление информации: Смена владельца. 79 Изменение контактной информации. Изменение статуса. … Вы можете использовать наряды для планирования автоматического обновления КЕ. Определение плановых простоев. Вы можете указать детали плановых (повторяющихся) простоев для КЕ. Планирование периодических простоев имеет следующие преимущества: Работники центра технической поддержки могут дать ответ на обращения, зарегистрированные во время простоя. Инициаторы могут быть информированы о простое, а также уведомлены об окончании простоя. Информация о плановых простоях может перенаправляться в средства мониторинга, для подавления возникающих сообщений на время проведения планового простоя. Если КЕ испытывает случайный (связанный с инцидентом) простой, данная информация может быть зарегистрирована в наряде на работы влекущие простой. Удаление конфигурационных единиц. Удаление конфигурационных единиц является сравнительно простым процессом, к которому необходимо относиться с осторожностью. При 80 удалении КЕ, помните о важности взаимосвязей, которые вы создавали. Если одна из КЕ связана с другой КЕ, удаление одной из них может привести к проблемам. Например, некий пользователь зарегистрировал обращения, связанные с отказами сервера. Специалистами было принято решение о замене данного сервера. При попытке удаления КЕ, может появиться уведомление о зависимых записях, относящихся к данной КЕ. Как результат, сначала необходимо удалить ссылающиеся на данную КЕ обращения, после чего КЕ может быть удалена из CMDB. Зависимости конфигурационных единиц. Записи конфигурационных единиц могут содержать не только информацию об элементах активов инфраструктуры ИТ, а также описывать зависимости элементов инфраструктуры. Например, если вы идентифицируете сервер как конфигурационную единицу и относящийся к нему монитор, отказ монитора повлияет на конфигурационную единицу сервер, и наоборот. Зависимость между данными двумя конфигурационными единицами должна быть описана. При использовании системы центра обслуживания, подобные зависимости могут быть описаны несколькими способами. Каждая КЕ может являться компонентом другой КЕ, устанавливания иерархическую зависимость типа родитель-потомок. В нашем примере с сервером и монитором, сервер идентифицирован как родитель, а монитор как потомок. В зависимостях типа родитель-потомок, потомок не может функционировать корректно при отказе родителя. Этот тип зависимости задаёт иерархии между КЕ. Также вы можете определять зависимость без иерархии. При установке прямой зависимости между КЕ, они находятся на одном уровне иерархии. Например, сервер и CPU-switch. Сервер и CPUswitch имеют один уровень иерархии, потому что они могут функционировать корректно по отдельности. Пример. Пакетная регистрация КЕ. Ивану Иванову, менеджеру конфигураций «Ы и компания», потребовалось пакетное задание для регистрации 6 серверов, закупленных департаментом разработки. Он выбирает помощника генерации КЕ. 81 Он выбирает существующий шаблон, хранящий большинство характеристик данных серверов. Затем он указывает необходимое количество конфигурационных единиц и открывает шаблон, для указания деталей генерации данных конфигурационных единиц. 82 Специфические детали данного пакетного задания включают в себя указание родительской КЕ (все серверы подключены к коммутатору № 1). 83 Каждый сервер поставляется с определённой операционной системой и набором предустановленного программного обеспечения. 84 Коды поиска конфигурационных единиц являются продолжением последовательности кодов поиска данного шаблона. 85 Т.к. используется система нумерации кодов поиска и в основных параметрах системы установлена опция принудительного обеспечения уникальности кодов поиска, система центра обслуживания отобразит предупреждение, указывающее, что нумерация не может начинаться с 001, но может начаться с первого доступного номера. После окончания процесса генерации КЕ, Иван просматривает отчёт генерации КЕ. 86 Ну и, наконец, Иван производит проверку иерархии сгенерированных КЕ. Определение ролей, относящихся к системе центра обслуживания. Ваши задачи, как менеджера конфигураций, оказывают прямое влияние на задачи, определяемые большинством ролей системы центра обслуживания. Вы не только должны определить, какие роли имеют доступ к КЕ и договорам обслуживания, а также должны гарантировать, что определяемые вами политики и процедуры согласованно применяются. Роли системы центра обслуживания могут включать в себя: Системный администратор. С системным администратором вы можете определять доступ к КЕ, представлениям данных, шаблонам, а также определять обязательные к заполнению поля в формах КЕ, необходимых вашей организации. Системный администратор производит выполнение ваших планов и определяет, какие роли имеют доступ к тем или иным элементам системы центра обслуживания. Персонал центра технической поддержки. Персонал центра технической поддержки обращается к КЕ при регистрации обращений, инцидентов, проблем и т.п. Специалисты. Специалисты обращаются к КЕ при разрешении обращений, инцидентов, проблем и т.п. 87 Менеджеры изменений. Регистрируемые вами КЕ анализируются, с целью применения к ним изменений, как реактивных, так и проактивных. Менеджеры изменений, также, могут контактировать с вами по поводу изменения КЕ и проведения закупок новых КЕ. Менеджеры проблем. Управляемые вами КЕ могут использоваться менеджерами проблем, для анализа тенденций возникновения инцидентов. Администраторы персон и организаций. Администраторы персон и организаций определяют необходимый перечень и детализацию информации описания КЕ вместе и профессионалами, предоставляющими поддержку и владельцами КЕ. 88 8. Задачи специалиста. Данная глава кратко описывает круг задач специалистов, включённых в предоставление услуг и управление уровнем обслуживания. Администрирование действий специалистов. Консоль центра обслуживания является вашим основным инструментом для управления и разрешения обращений поступающих от заказчиков, контактных персон, менеджеров изменений и менеджеров проблем. Консоль позволяет вам выполнять следующие задачи: Выбирать открытые обращения пользователей. Реагировать на инциденты. Просматривать записи аудита КЕ и информацию. Устанавливать статусы обращений. Устанавливать статусы изменений. Редактировать существующие обращения и инциденты. Вводить информацию учёта времени и стоимости. Панель ссылок системы центра обслуживания содержит все ссылки на процессы, которые вам необходимы. Вы можете выбрать любую из ссылок, например ссылку «Обращения» и отобразится представление по умолчанию для обращений. Вы можете выбирать заголовки столбцов для проведения сортировки по возрастанию или убыванию. Вы можете использовать представление «Сервис сегодня» для отображения всех элементов, назначенных вам или вашей рабочей группе. Для получения более подробной информации о редактировании и отображении обращений обратитесь к справочной информации системы центра обслуживания. Принятие обращений. Когда обращение назначается вашей рабочей группе для обработки, вы должны тщательно зафиксировать последовательность действий по разрешению обращения. Основной расход вашего времени должен быть направлен на разрешение обращений, а не на документирование действий. Система центра обслуживания оказывает помощь в данном вопросе; конечно, основная информация описания работ должна быть зафиксирована в системе. В соответствии с вашей работой, достигаются следующие основные цели: Решения поставляются напрямую заказчику. Решения могут быть повторно использованы. Решения могут использоваться для выполнения превентивных действий. Следующие поля являются обязательными полями для заполнения: Статус. По умолчанию существует 6 основных значений состояний. Названия могут быть изменены системным администратором, но функциональный смысл от этого не 89 меняется. Системным администратором, также, могут быть определены дополнительные статусы. Описание. Данное поле предоставляет краткое описание возникшего события. Заметка. Другие поля также могут быть обязательными для заполнения, что определяется менеджером инфраструктуры ИТ по согласованию с администратором системы обслуживания. По умолчанию, обязательные для заполнения поля отображаются полужирным шрифтом. Вы можете самостоятельно изменить формат отображения обязательных полей. Просмотр обращений. Вы можете устанавливать собственные критерии вывода выбранных обращений в консоли системы обслуживания, например, по специалистам. Используя панель инструментов, вы можете отображать информацию: Выбирая действие обзора из доступных действий в меню «Действия». Используя расширенный поиск в меню «Утилиты». Для получения более подробной информации по использованию меню «Действия» обратитесь к справочной информации системы центра обслуживания. Обновление обращений. При разрешении обращений, инцидентов и проблем, необходимо создавать соответствующие комментарии в нарядах системы центра обслуживания. Наряды содержат подробности работ, которые вы выполняете или собираетесь выполнять. Для получения более подробной информации по обновлению элементов системы центра обслуживания обратитесь к справочной информации системы центра обслуживания. В основном, при разрешении обращения заказчика и обработке других элементов, вы должны фиксировать все производимые вами действия. Ваши решения и обходные решения могут стать темой раздела «ЧаВо». Имея доступ к разделам «ЧаВо», заказчики могут самостоятельно решать возникающие проблемы без обращения в службу технической поддержки, экономя при этом своё и ваше время. Закрытие обращения. В зависимости от процессов, принятых в вашей компании, возможно, возникнет необходимость закрытия обращения, когда оно разрешёно или заказчику предоставлено обходное решение. Относитесь внимательно к предоставлению «быстрых решений» и смене статуса обращения в «Закрыто». Не забывайте, вместе с закрытием обращения, закрывать соответствующие наряды. Если по обращению созданы наряды, то 90 наряды должны быть закрыты перед тем как будет закрыто обращение. Создание обращений субподрядчику. Иногда возникает необходимость создания обращения к сторонним поставщикам услуг, для решения причин возникновения инцидентов и проблем. В таких случаях создаётся «Обращение субподрядчику». Система центра обслуживания автоматически копирует часть информации оригинального события и регистрирует вас в качестве инициатора. Пример. Создание обращения субподрядчику включённого в предоставление операционного уровня услуг. При достижении пороговых значений производительности СУБД, автоматически создаётся запись инцидента. Персонал службы технической поддержки может связать обращения пользователей с данным инцидентом, и данный инцидент может быть назначен рабочей группе администраторов БД. Рабочая группа администраторов БД обнаружила, что низкая производительность СУБД связана с изменением параметров системы UNIX-сервера. Рабочая группа АБД создаёт временное решение инцидента путём временного изменение параметров инициализации экземпляра СУБД. Персонал службы технической поддержки может закрыть обращение, связанное с данным инцидентом, и изменить статус инцидента, указывающего на то, что инцидент обработан, но пока не закрыт. Рабочая группа АБД создаёт запись обращения субподрядчикурабочей группе обслуживания UNIX-серверов. Запись обращения субподрядчику указывает на необходимость возвращения параметров инициализации ядра UNIX-сервера к предыдущим значениям, при которых была зафиксирована устойчивая работа СУБД. Когда рабочая группа АБД уведомляется о возвращении параметров к первоначальным значениям – она возвращает параметры инициализации СУБД в исходное состояние и закрывает инцидент. Пример. Создание обращения субподрядчику включённого в предоставление бизнес-услуг. Обнаружен инцидент, указывающий на низкую производительность Интернет-системы, предоставляемой заказчику. Корневая причина была обнаружена и указала на снижение пропускной способности линий связи внешнего поставщика услуг Интернет (ISP). На внутреннем уровне было принято решение по распределению нагрузки на систему по резервным каналам связи. Из данного инцидента было создано обращение субподрядчику о необходимости восстановления пропускной способности магистральных линий связи. 91 Зависимости элементов системы центра обслуживания. Образуя зависимости элементов системы центра обслуживания, вы получаете возможность проактивно решать возникающие проблемы. Зависимости предоставляют дополнительную информацию обращений с похожими симптомами. Если зависимые элементы закрываются, то вы можете просмотреть предлагаемое решение, является ли оно известной ошибкой или предоставленным решением. Проверяя зависимые объекты, такие как обращения, инциденты, изменения или проблемы, вы можете существенно сэкономить своё время. Следующий рисунок отображает зависимость между инцидентом и обращением. Пример. Анализ проблемы. Ивану Иванову, участнику группы специалистов по СУБД, компании «Ы и компания», было назначено задание исследования низкой производительности СУБД. Он открыл назначенный ему наряд, открыл панель, отображающую зависимости, и открыл зависимый инцидент. 92 Просматривая информацию зависимости проблемы, он видит, что проблема вызвана инцидентом. 93 Он открывает данный инцидент для более подробного изучения. 94 Основываясь на дополнительной информации инцидента и диагностических средств СУБД, Иван находит причину возникновения инцидента. Иван прикрепляет отчёт к наряду и изменяет статус наряда на «Выполнен». Также переназначает его обратно инициатору, который теперь может произвести необходимые изменения по решению проблемы, основываясь на исследованиях Ивана. Определение зависимых ролей системы центра обслуживания. Ваша роль, как специалиста, имеет зависимости со следующими ролями системы центра обслуживания: Менеджер изменений. Менеджер изменений может инициировать изменения, которые вам будет необходимо применить. Запросы на изменения могут сопровождаться нарядами, которые вам также необходимо обработать. Обращения, регистрируемые вами, анализируются на предмет проведения реактивных и проактивных изменений. В дополнение, вам может потребоваться уведомление заказчиков о необходимости проведения изменений. Менеджеры проблем. Менеджеры проблем могут инициировать исследования, которые вам необходимо выполнить. Проблемы, также, могут сопровождаться нарядами, которые вам необходимо обработать. 95 Менеджер уровня обслуживания. Соглашение об уровне обслуживания определяет уровни обслуживания и перечень услуг, предоставляемых пользователям. Менеджер уровня обслуживания должен консолидировать ресурсы и анализировать время реакции для создания реалистичного соглашения об уровне обслуживания. Ваше время реакции для всех процессов системы центра обслуживания окажет поддержку в проведении переговоров менеджера уровня обслуживания с заказчиками на предмет составления соглашения об уровне обслуживания. Персонал центра технической поддержки. Обращения, которые регистрируют, но не могут решить операторы, могут быть назначены вам. 96 9. Задачи менеджера изменений. Управление изменениями включает в себя управление планированием изменений вашей инфраструктуры ИТ. Это включает в себя планирование изменений, предоставление подробной информации по операциям изменения, планирование простоев, и удаление изменений. Администрирование изменений. Вы можете идентифицировать проводимые изменения в системе центра обслуживания из центральной консоли. Когда у вас возникает необходимость добавления изменения - отображается форма, аналогичная приведённой ниже: Утверждение изменений. Обеспечение критичных бизнес-процессов зависит от скорости принятия решений. Для соблюдения договорённости по обеспечению необходимых уровней обслуживания, необходимо выполнить некоторые действия, которые должны быть авторизованы. Должно гарантироваться, что необходимые специалисты будут включены в процесс принятия решений до процесса непосредственного исполнения, что является критичным для эффективного выполнения соглашений. При авторизации процесса управления ИТ ручной контроль необходимых действий является неэффективным и затратным по времени процессом,. Система утверждений центра обслуживания является структурированным, процесс-ориентированным механизмом, который предоставляет эффективные методы управления и авторизации процессов управления ИТ. 97 Просмотр изменений. Запросы изменений могут быть просмотрены и изменены несколькими способами в консоли системы центра обслуживания. Вы можете просматривать изменения из представления данных «Изменения». Также, вы можете просматривать изменения следующими способами: Выбирая действие обзора из меню «Действия». Например, при просмотре списка всех конфигурационных единиц, вы можете выбрать действие обзора для отображения всех изменений связанных с выбранной конфигурационной единицей. Пользуя расширенный поиск. Обновление конфигурационных единиц. Вы можете назначать наряды на проведение изменений, которые включают в себя модификацию значений атрибутов конфигурационных единиц, вы можете использовать триггерную логику для автоматического изменения атрибутов элементов при изменении статуса КЕ. Закрытие изменений. При закрытии запроса на изменение, вы должны обновить статус изменения на «Закрыто». Периодически вам будет необходимо закрывать изменения, не требующих проведения действий. Например, запрос на изменение, который заведён по ошибке или дублирует существующий запрос на изменение, не требует выполнения каких-либо действий и должен быть закрыт или удален. Ваша рабочая группа управления инфраструктурой ИТ должна определить, какие действия необходимо выполнять в подобных случаях. Удаление изменения. Если принято решение об удалении подобных записей из системы центра обслуживания – будьте с этим осторожны, используйте операцию подтверждения удаления. Запись будет удалена навсегда из системы центра обслуживания при использовании комбинации клавиш CTRL-D. Если оператор системы центра обслуживания связал данное изменение с элементами системы – могут возникнуть некоторые затруднения. Изменение статуса на «Закрыто». Может быть принято решение о закрытии подобных элементов, например, при дублировании. В таком случае выбирается код закрытия «Отменен», но возможно имеет смысл создать дополнительный код закрытия как «Дублирующий». 98 Планирование периодических простоев. Система центра обслуживания предоставляет средства планирования периодических простоев, которые позволят вам минимизировать влияние простоев, необходимых при, например, проведении операций обслуживания оборудования. Планирование периодических простоев имеет следующие преимущества: Сотрудники технической поддержки могут выбрать «окно» для проведения работ связанных с простоем, с минимальным влиянием на сервисы, которые используют данные конфигурационные единицы. Сотрудники технической поддержки имеют готовый ответ на обращения, регистрируемые во время проведения планового простоя КЕ. Инициаторы могут быть информированы о планируемом простое, а также могут быть уведомлены об окончании простоя и восстановлении работоспособности сервиса. Информация о плановых простоях может использоваться для подавления поступающих сообщений от систем мониторинга, например, HP Open View Operations. Если необходимо проведение регулярных плановых простоев для КЕ, данная информация может содержаться в определении КЕ. Заметка. Планируемые периодические простои поддерживаются не только в нарядах связанных с изменениями, но и в нарядах, связанных с обращениями, инцидентами, проблемами, проектами. 99 Периодический простой указывается в наряде для задачи, требующей простой: При выполнении двойного нажатия на соответствующей КЕ, отображается диалоговое окно, где вы можете указать, что соответствующая КЕ затронута простоем. Для периодических простоев вы можете указать напрямую период простоя, или система центра обслуживания может произвести калькуляцию времени «окна», который производит подсчёт времени, при котором оказываемое простоем влияние будет минимальным. 100 Калькуляция времени «окна» учитывает режим работы службы технической поддержки и часовой пояс, что является особенно актуальным при проведении простоя некоторого множества КЕ. Передача информации в HP Open View Operations. Информация о планируемых простоях может быть передана в HP Open View Operations for Unix для подавления поступающих сообщений от объектов мониторинга на время проведения простоя. При периодическом простое, указанном в наряде, передаётся информация простоя для каждой задействованной конфигурационной единицы. Информация, отправляемая в HP Open View Operations, включая расписание повторений и расписание проведения простоев, переменные условий статуса, задействованные приложения, безотлагательность и сообщение и деталях операции. Обновление КЕ согласно наряду. При планировании изменений атрибутов КЕ, вы можете указать планируемые значения в наряде, а также вы можете использовать триггерную логику для автоматической установки новых значений атрибутов при смене статуса состояния записи изменения. Хотя большинство задач планирования изменений, связанных со сменой значения атрибутов, включают в себя физическое перемещение КЕ, смену владельца, смену ответственного лица, вы можете планировать изменение любого простого значения атрибута КЕ (это атрибут, который содержит одно значение, в отличии, например, от списка значений). Указание планируемых значений атрибутов. Вы можете указать изменения атрибутов для любой КЕ, указанной в наряде. Планируемые значения атрибутов указываются в «КЕ/простой» окне, которое отображается при связи КЕ с нарядом. Например, следующий рисунок отображает планируемое изменение расположения КЕ: 101 Окно «КЕ/простой» отображает имена атрибутов с текущими значениями каждого из атрибутов (пустые поля обозначают отсутствие какого-либо значения для данного атрибута), и планируемые значения атрибутов (пустые поля обозначают отсутствие изменения значения атрибута). Наряд, изображённый на следующем рисунке, использует триггерную логику для проведения обновления двух КЕ, как только статус наряда будет в состоянии «Готов». 102 Флаг «КЕ обновлены» указывает на окончание процесса проведения обновления значений атрибутов КЕ. Планируемые значения не могут изменяться повторно. Назначение менеджера изменений. Менеджер изменений может быть указан в поле менеджер в сущности изменения. Добавление или удаление менеджеров изменений может производить только администратор системы центра обслуживания. Проверка зависимости КЕ с другими нарядами на изменения. Если КЕ изменяется в более чем одном наряде, вы можете рассмотреть вопрос раздельного изменения атрибутов в каждом из нарядов. При связывании КЕ с нарядом, система центра обслуживания каждый раз производит проверку наличия связи КЕ с другими нарядами. Если наряд найден и дата его завершения ещё не достигнута, идентификаторы изменений выводятся во всплывающем диалоговом окне: 103 После чего вы можете проверить планируемые изменения атрибутов в данном наряде для устранения дублирующих изменений. Пример. Планирование изменения. Иван Иванов, менеджер изменений, является ответственным лицом за добавление дополнительного ЦП в WEB-сервер. Данное изменение уже утверждено, но оно ещё должно быть запланировано и задачи проведения изменения должны быть назначены. Он добавляет некоторое количество нарядов в изменение и назначает соответствующих специалистов для исполнения. 104 Задача включает в себя конфигурирование резервного сервера для временной замены перегруженного промышленного сервера, закупку модуля ЦП, установку ЦП и оценку улучшения производительности. Все задачи сгруппированы вместе, для обозначения зависимостей, так что одна задача не может быть выполнена пока не будет завершена предыдущая. Например, установка модуля ЦП может быть выполнена только после закупки и доставки данного модуля, и будет настроен резервный сервер для временной замены, но две предыдущие задачи могут быть выполнены одновременно. Иван использует представление проекта в виде диаграммы GANTT, для проверки расписания выполнения работ. Идентификация зависимых ролей системы центра обслуживания. Ваша роль, менеджера изменений, взаимодействует со следующими ролями системы центра обслуживания: Менеджер конфигураций. Менеджер конфигураций проводит классификацию активов инфраструктуры ИТ требующих проведения изменений. Менеджер проблем. Ваша роль тесно взаимодействует с менеджером проблем. Менеджер проблем создаёт большинство запросов на изменения, требующих вашего участия. Менеджер проблем анализирует проблемы и повторяющиеся инциденты. Как только обозначается корневая причина возникновения инцидентов и проблем – регистрируется изменение. Персонал центра технической поддержки. Операторы центра технической поддержки регистрируют обращения, которые вы анализируете для поиска КЕ требующих изменений. Менеджер уровня обслуживания. Соглашения об уровне обслуживания регламентируют предоставляемые уровни обслуживания и перечень услуг, предоставляемых заказчику. Менеджер уровня обслуживания напрямую влияет на объёмы предоставляемых услуг и изменения КЕ, которые вы, как менеджер изменений, и специалист должны предоставить. 105 Специалисты. Специалисты проводят планируемые вами изменения. Специалисты должны тесно с вами взаимодействовать для уточнения расписания проведения изменений. Вы не должны закрывать изменения, пока не будет получено подтверждение от специалистов об окончании проведения изменения. 106 10. Задачи менеджера проблем. Данная глава описывает основной подход, которого может придерживаться менеджер проблем при использовании системы центра обслуживания. Также предоставлены основы реактивного и проактивного управления проблемами. Администрирование задач менеджера проблем. Менеджер проблем идентифицирует и решает проблемы инфраструктуры ИТ для поддержания предоставления качественных услуг ИТ. Менеджер проблем также пытается идентифицировать дефициты предоставления услуг или функций поддержки услуг, особенно те, которые ведут к возникновению повторяющихся инцидентов. Решая проблемы, менеджер проблем стремится уменьшить количество возникающих инцидентов, а также уменьшить их влияние и риски повторного возникновения. Менеджер проблем является не только ролью, реагирующей на повторяющиеся инциденты, но и ролью принимающей активное участие в действиях требующих проведение изменений. Вы можете идентифицировать проблему до регистрации обращения. Например, при переезде департамента вы можете определить, что переезд является проблемой, и может привести к возникновению множества инцидентов в связи с отсутствием сетевых соединений или отсутствие сетевых периферийных устройств и пр. Зарегистрированные проблемы отображаются в представлении проблемы. 107 Целью регистрации проблем является поиск корневых причин возникновения инцидентов в инфраструктуре ИТ. При нахождении причины возникновения проблемы, может быть выдвинуто и выполнено решение по устранению данной проблемы. После нахождения решения устранения проблемы, проблема принимает статус известной ошибки. Как менеджер проблем, вы можете идентифицировать известные ошибки, и на основе ваших данных, менеджер изменений может предоставить решение. Анализ зарегистрированных обращений и инцидентов является важнейшей задачей вашей роли. Вы должны анализировать обращения и инциленты для идентификации проблем, которые должны быть устранены. Регистрация проблем. Сбор детализированной и точной информации является важным действием при регистрации и разрешении проблемы. Информация, вводимая менеджером проблем, является основой для менеджера изменений, который, в свою очередь, инициирует предложения по внесению изменений в инфраструктуру ИТ. При регистрации новой проблемы отображается форма, аналогичная приведённой ниже. 108 Следующие поля являются обязательными для заполнения: Описание. Должно быть предоставлено точное и краткое описание возникшей проблемы. Описание является отправной точкой решения проблемы. Также описание может послужить темой часто задаваемых вопросов (ЧаВо) поддерживаемых сервисными страницами. Статус. При нажатии стрелки вниз в поле статуса, отображается список статусов для описания состояния проблемы. Вы не можете вводить в данное поле произвольный текст, значение выбирается только из списка, который устанавливается администратором системы центра обслуживания. Например, для отображения состояния зарегистрированной проблемы, вы можете выбрать статус «Зарегистрирован». Заметка. Другие поля также могут быть обязательными для заполнения, что определяется менеджером инфраструктуры ИТ по согласованию с администратором системы обслуживания. По умолчанию, обязательные для заполнения поля отображаются полужирным шрифтом. Вы можете самостоятельно изменить формат отображения обязательных полей. 109 Зависимости элементов системы центра обслуживания. Как часть работы по регистрации проблемы, вы должны определить зависимости проблемы с обращениями, инцидентами и изменениями. Устанавливая зависимость проблемы с элементами системы центра обслуживания, вы оказываете содействие по вопросам предоставления решений по устранению проблем менеджеру изменений. Менеджер изменений может анализировать зависимые элементы: При проведении исследования проблемы и предоставления решений, статусы зависимых элементов устанавливаются как «Известная ошибка». Другие авторизованные пользователи могут просматривать решение и предпринимать соответствующие действия. Например, представьте ситуацию, в которой вы создаёте запись проблемы и связываете её с несколькими открытыми и закрытыми обращениями и инцидентами. Специалисты, занятые решением данных проблем и обращений, обработали их и предложили обходное решение. Специалисты знают, что менеджеры инфраструктуры осведомлены о проблеме и могут сказать конечным пользователям, что ведутся работы над постоянным решением. 110 Пример. Регистрация проблемы. Иван Иванов, являющийся менеджером проблем, производя анализ зарегистрированных обращений по определённому WEB-серверу, идентифицирует проблему, требующую дополнительного исследования. Он выбирает наиболее подходящий инцидент из списка инцидентов и регистрирует проблему, на основе данных инцидента. Система центра обслуживания создаёт запись проблемы, в которую копируется информация из записи инцидента. Иван изменяет информацию полей «Описание» и «Информация» и закрывает проблему. Система центра обслуживания отображает диалоговое окно, в котором Иван указывает тип зависимости, которое имеет проблема с инцидентами. В нижеприведённом примере проблема вызвана инцидентом. 111 Определение зависимости теперь отображается в списке зависимостей проблемы. Иван затем добавляет наряд, для проведения работ по исследованию корневых причин возникновения проблемы. 112 Наряд назначается группе специалистов по WEB-серверам. Пример. Инициация изменения. Иван Иванов, являющийся менеджером проблем, получает закрытый наряд на работы по исследованию нагрузки ЦП WEB-сервера. Отчёт указывает, что перерасход ресурсов ЦП происходит в определённое время в определённые дни недели. Иван принимает решение о добавлении модуля ЦП в WEB-сервер. Он открывает соответствующую запись проблемы, изменяет её статус на «Ожидание изменения (RFC)» и добавляет принятое решение как новый тип зависимости наряда «Разрешённый». 113 Открывается форма заведения нового запроса на изменение. Иван предоставляет основную информацию, описывающую смысл данного изменения. Политика проведения изменений компании предусматривает проведение процесса утверждения изменения, таким образом, Иван вносит имя инициатора в поле «Иниц. утверждения», что производит активацию процесса утверждения. 114 Когда Иван сохраняет и закрывает форму, система центра обслуживания размещает запрос на изменение в представлении «Сервис сегодня» менеджера изменений. Менеджер изменений теперь получает возможность контроля процесса утверждения изменения. Идентификация зависимых ролей системы центра обслуживания. Менеджер проблем взаимодействует со следующими ролями системы центра обслуживания: Менеджер изменений. Менеджеры проблем должны тесно сотрудничать с менеджерами изменений. Менеджер проблем является инициатором множества запросов на изменение. Менеджер конфигураций. Ваша роль является ключевой ролью для менеджера конфигураций. Без вашей точной идентификации повторения обращений, менеджер конфигураций не осведомлён о необходимости проведения изменений инфраструктуры ИТ. Персонал центра технической поддержки. Операторы центра технической поддержки регистрируют анализируемые вами обращения. Вы должны анализировать их на предмет наличия повторений и выполнения реактивных и проактивных действий по устранению причин их возникновения. Менеджер уровня обслуживания. Соглашения об уровне обслуживания регламентируют предоставляемые уровни обслуживания и перечень услуг, предоставляемых заказчику. Менеджер уровня обслуживания напрямую влияет на объёмы 115 предоставляемых услуг и количество КЕ, которые вы, как менеджер проблем, и специалист должны предоставить. Специалисты. Анализируя исследования специалистов, вы можете определять известные ошибки. Также персонал создаёт отчёты о повторениях возникновения ошибок инфраструктуры. Специалисты должны тесно с вами сотрудничать для предоставления детализированных постоянных и обходных решений по известным ошибкам. 116 11. Задачи менеджера уровня обслуживания. Данная глава предоставляет рекомендации и краткую справочную информацию по определению структуры сервисов, определению соглашений об уровне обслуживания, и контролю их производительности. Глава включает информацию по разработке, созданию, и определению соглашений об уровне обслуживания. Определение структуры сервисов. Процесс эффективного управления уровнем обслуживания основывается на однозначном понимании зависимостей различных сервисов, включённых в инфраструктуру ИТ. Система центра обслуживания помогает менеджеру уровней обслуживания в достижении понимания этого процесса следующими способами: Позволяет регистрировать сервисы соответственно их типам. Позволяет производить декомпозицию структуры сервисов, точно описывающие их внутренние зависимости. Произведение декомпозиции структуры сервисов даёт преимущества при поиске корневых причин возникновения проблем и при анализе влияния компонентов: Возможность группировки обращений, инцидентов и проблем по конфигурационным единицам или сервисам. Однозначное понимание влияния возникающих событий и корневых причин проблем. Лёгкое определение действующего соглашения об уровне обслуживания при устранении ошибок. Возможность определения влияния ошибок на функционирование сервисов того же уровня и более низкого, а также воздействие отказа КЕ на функционирование сервиса. Быстрый поиск поставщиков услуг, которым должны переадресовываться вопросы по отказам определённых сервисов или услуг. Проверка «подпирающих» (underpinned) уровней обслуживания (уровни обслуживания субподрядчиков и поставщиков услуг). Типы сервисов. Все основные методологии управления инфраструктурой ИТ, проводят различия между типам сервисов. Выполнение разделения сервисов по типам, позволяет определить различные типы зависимостей между различными сервисами и конфигурационными единицами. Система центра обслуживания различает следующие типы сервисов: Бизнес-сервисы. Сервисы операционного управления. Подпирающие сервисы. Бизнес-сервисы. Бизнес-сервисы являются средством, предоставляющим мощности для обработки бизнес-транзакций и(или) мощности системных ресурсов. Это включает все сервисы, предоставляемые заказчику, в соответствии с соглашением об уровне обслуживания, определённой стоимости и некоторое количество подчинённых сервисов, которые 117 не предоставляются заказчику напрямую (вспомогательные). Некоторые подчинённые сервисы должны закупаться у сторонних поставщиков услуг. Примерами бизнес-сервисов являются сервисы приложений, сетевые сервисы, услуги хостинга. Сервисы операционного управления. Сервисы операционного управления являются сервисами, предоставляющими средства администрирования и отказоустойчивости аппаратных и программных средств инфраструктуры, используемыми бизес-сервисами. Обычно организация, предоставляющая бизнес-сервисы, проводит разделение зон ответственности управления ресурсами инфраструктуры (таких как ЛВС, базы данных, системное администрирование), в соответствии с используемыми ресурсами бизес-сервисов. Более того, определённые зоны ответственности могут быть переданы на обслуживания сторонним организациям (outsource). Это, в основном, относится к сравнительно зрелым сервисам операционного уровня, которые специалисты могут предоставлять по более низкой стоимости, чем предоставление этих услуг поставщиком бизнес-сервисов. Подпирающие сервисы. Когда обслуживание определённых зон ответственности передаётся сторонним организациям (например, обслуживание инфраструктуры или задачи восстановления), предоставление стороннего сервиса определяется как подпирающий сервис. По определению должны быть зависимости между подпирающими сервисами и сервисами операционного управления, которые они поддерживают, а также между подпирающими сервисами и конфигурационными единицами, которые он должен поддерживать. Зависимости сервисов. С момента, как менеджер уровня обслуживания определит перечень функционирующих в инфраструктуре сервисов, следующим шагом будет определение зависимостей сервисов относительно друг друга и относительно задействованных в них конфигурационных единицах. В соответствии с лучшими методологиями по управлению инфраструктурой (речь идёт об Information Technology Infrastructure Library, на соответствие которой сертифицирована система центра обслуживания), система центра обслуживания различает несколько типов зависимости, о каждом из которых описывается ниже. Зависимость типа «родительский-дочерний». Определённый сервис может состоять из некоторого подмножества элементов, каждый из которых представляется в виде отдельного сервиса. Зависимость типа «родительский-дочерний» может существовать, например, между бизнес-сервисами и сервисами операционного управления. 118 В качестве примера зависимости типа «родительский-дочерний» между бизнес-сервисами, где поставщик услуг предоставляет полное решение по управлению цепочками поставок торговым партнёрам компании. Обычно основным заказчиком является предприятие, которому требуется соглашение об уровне услуг, покрывающее родительский сервис полностью. Заказчики и дистрибьюторы торговой компании, однако, нуждаются в предоставлении только определённых дочерних компонентов системы, которым необходимо соглашение об уровне обслуживания, которое покрывает только определённую категорию предоставляемых дочерних сервисов. Зависимость типа «использует-используем». Определённые бизнес-сервисы могут использовать (т.е. быть зависимыми от) других бизнес-сервисов, и могут выступать сами в роли источника для других бизнес-сервисов. Это является иерархической формой зависимости, которое содержит определения бизнес-сервисов до самого высокого уровня, нижние уровни сервисов являются нижним уровнем иерархии, и конфигурационные единицы являются «дном» (самым нижним уровнем иерархии). Используемые бизнес-сервисы могут предоставляться как внутренними поставщиками услуг, так и внешними. Зависимость типа «управляющий-управляем». Зависимости данного типа существуют между сервисами операционного управления и конфигурационными единицами, над которыми подразумевается проведение действий администрирования. Зависимость типа «поддерживающий-поддерживаем». Зависимости данного типа существуют между подпирающими сервисами и конфигурационными единицами, для которых подразумевается наличие определённых областей ответственности. Например, ремонт или замена аппаратного обеспечения. Зависимость типа «подпирающий-подпираем». Зависимости данного типа существуют между подпирающими сервисами и сервисами операционного управления, которые передают определённые зоны ответственности сторонним организациям (outsource), такие как ремонт и замена оборудования. Допустимые структурные зависимости для сервисов и КЕ. Следующая таблица отображает, какие типы зависимостей являются допустимыми между типами сервисов и конфигурационными единицами. Для чтения таблицы выберете сущность в левом столбце таблицы и посмотрите какую из типов зависимостей он допускает на пересечении с заголовком таблицы. 119 Использует, родительский Сервис операционного уровня Подпирающий сервис Конфигурационная Используем единица Конфигурацион ная единица Подпирающий сервис Сервис операционного управления Бизнес-сервис Бизнес-сервис Тип Использует Родительский Подпираем Подпирающий Управляем Управляет Поддерживает Поддерживающий Использует, родительский Пример. Определение структуры сервисов. Иван является ответственным за внедрение процесса управления уровнем обслуживания в компании. Как часть данного процесса, он решает определить структуру сервисов в системе центра обслуживания. В целях упрощения, данный пример представляет упрощённое представление инфраструктуры ИТ для рассмотрения. Иван начинает анализировать сервисы, предоставляемые внутренним потребителям. Компания предоставляет комплект Internet-решений, состоящий из двух сервисов: электронная почта и услуги предоставления доступа в Internet (включая доступ к удалённым компьютерам, передачу файлов и пр.). Заказчики могут использовать как комплект целиком, так и по отдельности. Каждый сервис доступен по двум уровням обслуживания: в рабочее время (8x5) и круглосуточно (24x7). Следующий рисунок отображает декомпозицию бизнес-сервисов: 120 Комплект бизнес-сервисов Тип зависимости «Родительский-дочерний» Internet E-Mail Каждый бизнес-сервис зависит от сервиса Интернет соединения, и данная зависимость проиллюстрирована на следующем рисунке. Сервис Интернет-соединения предоставляется сторонней компанией. Хотя данный сервис не предоставляется потребителям услуг Ивана, его недоступность будет оказывать влияние на работоспособность сервисов Internet и E-Mail. Комплект бизнес-сервисов Тип зависимости «Родительский-дочерний» Internet E-Mail Использует Соединение с Internet 121 Иван теперь рассматривает конфигурационные единицы, используемые бизнес-сервисами. В действительности, сервис e-mail предоставляется несколькими серверами с установленным ПО на каждом из них. Упрощая далее пример, мы предполагаем, что сервис e-mail использует две конфигурационные единицы: сервер e-mail и программное обеспечение e-mail. Исследование, проводимое менеджером конфигураций, определило, что данные конфигурационные единицы имеют тип зависимости «родительский-дочерний». И, наконец, Иван рассматривает сервисы операционного управления, которые управляют используемыми конфигурационными единицами. В данном примере, сервер HP, управляем внутренней группой сопровождения UNIX-серверов. Однако обслуживание аппаратной части сервера передано сторонней организации. Следующий рисунок изображает данную ситуацию. Следующий рисунок отображает все зависимости между бизнессервисами, конфигурационными единицами, сервисами операционного управления, и подпирающими сервисами: Автоматическое получение уровней обслуживания в инцидентах. При ручном или автоматическом создании инцидентов, система центра обслуживания получает наиболее соответствующий уровень обслуживания, что влечёт за собой автоматическую калькуляцию крайнего срока (deadline) разрешения инцидента. Содержание сервисной структуры определяет получаемый уровень обслуживания 122 (как показано ниже), и менеджеры уровня обслуживания должны быть осведомлены об этом, при составлении структуры сервисов. Следующий рисунок отображает используемые пути поиска системы центра обслуживания наиболее подходящего уровня обслуживания для назначения в инцидент. Инциденты, связанные с сервисом. Если инцидент связан с сервисом операционного управления, система центра обслуживания выполняет поиск по иерархии сервисов операционного управления и получает первое найденное соглашение об уровне обслуживания, вместе с определённым в нём уровнем обслуживания. Если соглашение об уровне обслуживания не найдено, система центра обслуживания устанавливает уровень обслуживания по умолчанию. Если инцидент связан с подпирающим сервисом с соглашением об уровне обслуживания, извлекается соглашение об уровне обслуживания вместе с его уровнями обслуживания. Если подпирающий сервис не имеет соглашения об уровне обслуживания, то применяется уровень обслуживания по умолчанию. Если инцидент связан с бизнес-сервисами, то более чем одно соглашение об уровне обслуживания может быть применено. Система центра обслуживания определяет перечень подходящих соглашений об 123 уровне обслуживания, определяет соглашение с наиболее строгим уровнем обслуживания и извлекает из него уровни обслуживания. Если найдено только одно соглашение об уровне обслуживания, оно извлекается вместе с его уровнями обслуживания. Инциденты, связанные с конфигурационными единицами. Если инцидент связан с конфигурационной единицей, система центра обслуживания осуществляет поиск элементов следующих типов: Сервис операционного управления конфигурационной единицей. Если данный сервис найден, система центра обслуживания осуществляет поиск соглашения об уровне обслуживания в иерархии сервисов. Если соглашение об уровне обслуживания найдено, оно извлекается вместе уровнями обслуживания; в противном случае, система центра обслуживания извлекает уровень обслуживания по умолчанию. КЕ с назначенным уровнем обслуживания. Если найдена, извлекается уровень обслуживания. Бизнес-сервис, использующий КЕ. Если найден бизнес-сервис, более чем одно соглашение об уровне обслуживания может быть найдено. Система центра обслуживания определяет перечень подходящих соглашений об уровне обслуживания, определяет соглашение с наиболее строгим уровнем обслуживания и извлекает из него уровни обслуживания. Если по данным критериям поиска система центра обслуживания не находит уровень обслуживания, поиск выполняется рекурсивно для каждой родительской конфигурационной единицы вверх по иерархии КЕ. Данный поиск выполняется только в том случае, если конфигурационная единица, указанная в инциденте, является уникальной, и поиск ограничен уникальными родительскими записями вверх по иерархии. Добавление сервисов операционного управления и подпирающих сервисов в структуру сервисов. При определении структуры сервисов, менеджер уровня обслуживания может выбирать, включить в структуру или нет сервисы операционного управления и подпирающие сервисы. Включение сервисов операционного управления в структуру сервисов наиболее подходяще для сравнительно сложных инфраструктур, где управление ресурсами разделено между группами специалистов по сферам компетенции (ЛВС, системное администрирование, администрирование баз данных и пр.). Процесс управления уровнем услуг может не испытывать преимущества включения сервисов операционного уровня услуг в сравнительно простых инфраструктур ИТ. Включение или исключение сервисов операционного управления также влияет на тип уровня обслуживания, который автоматически вносится в инцидент: В структуре сервисов, которая включает сервисы операционного управления, также как и бизнес-сервисы, выбор 124 извлекаемого уровня обслуживания имеют тенденцию к выбору уровня с временем реакции, которое максимально подходит для поставщика операционных услуг для выполнения своих обязательств по предоставлению определённого качества услуг. Эти соглашения имеют тенденцию быть более строгими, чем обязательства между поставщиками бизнес-сервисов и их потребителями. В структуре сервисов, которые содержат только бизнессервисы, извлекаемые уровни обслуживания имеют тенденцию к выбору наиболее подходящего времени реакции, которое необходимо соблюсти для выполнения обязательств между поставщиком бизнес-сервисов и заказчиками. Создание эффективных соглашений об уровне услуг. Соглашение об уровне обслуживания (Service Level Agreement) определяет содержание соглашение, по которому поставщик услуг предоставляет определённые услуги заказчику. Хотя применение SLA является функциональной частью системы центра обслуживания, вы можете работать с системой без детализированного процесса управления уровнем обслуживания. Соглашения об уровне обслуживания действительно только между датой фактического начала и завершения. С целью упрощения администрирования, вы можете создать SLA для нескольких получателей. Другой доступной опцией является использование шаблонов, для создания новых соглашений об уровне обслуживания. Будьте внимательны при создании по требованию соглашения об уровне обслуживания с применением шаблона. SLA, определяемое по требованию, может предоставлять услуги с отличным от принятого в компании уровня обслуживания. Следующий рисунок отображает как используется простое SLA для определения доступности сервиса АИИС КУЭ заказчику: 125 Определение расписания обслуживания соглашения об уровне обслуживания. Ваша организация может предоставлять различные уровни обслуживания, основанные на времени доступности сервиса. Например, на рисунке ниже, вы можете наблюдать, что бронзовый уровень облуживания определяется 8 часами в день, 5 дней в неделю, а золотой уровень обслуживания определяет работу 24 часа в сутки, 7 дней в неделю. 126 Поставщик услуг и получатель могут находиться в различных часовых поясах. Когда вы предоставляете услуги заказчику, в соглашении указывается, к каким часовым поясам применяется расписание обслуживания (поставщика или потребителя услуг). Составление соглашения об уровне услуг. Соглашения об уровнях услуг всегда существуют в организации, даже если конечные пользователи не знаю об их существовании. Пользователи думают, что соглашение об уровне услуг, составляемые департаментами ИТ, не требуют их участия и основываются на неких пороговых значениях производительности систем, которые им не понятны. Сегодня, составление соглашения об уровне услуг начинается с анализа потребностей пользователей для составления требований к инфраструктуре ИТ. Эффект от предоставления услуг низкого качества проблематичен в финансовом исчислении, но потенциальная стоимость сравнительно высока. Если инфраструктура заказчика имеет процент доступности в 80%, то это подразумевает, что 20% рабочего времени персонал не работает. Умножая этот результат на общее количество пользователей, вы можете получить более реалистическую стоимость убытков организации. Информационные технологии должны поддерживать бизнес заказчика. Если заказчики не доверяют информационным технологиям, в связи с низким уровнем доступности и качества, они не будут заинтересованы в использовании и развитии данных технологий. 127 Персонал может являться причиной предоставления низкого качества услуг ИТ. Если персонал ИТ не в состоянии обеспечить ожидания пользователей, то их деятельность чаще трактуется как «бездельники», чем что-то полезное. Обученный и опытный персонал, может испытывать стресс на работе, и принять решение об уходе из компании. Потеря контроля над уровнем услуг приводит к потере ценной информации обслуживания и снижает качество персонала. Одним из решений устранения низкого качества услуг является составление и применение соглашения об уровне услуг. Первым шагом в составлении соглашения об уровне обслуживания является проведение переговоров с владельцами бизнеса и персоналом технической поддержки. Проводя переговоры с бизнеспользователями, вы можете понять, что они подразумевают под типичным обращением и какое время реакции они ожидают. Затем проведите переговоры со своим техническим персоналом, обсудите их потребности в терминах их процессов и процедур, попробуйте связать вашу техническую терминологию с терминологией конечного пользователя. Проведите переговоры с персоналом технической поддержки для определения всех элементов соглашения об уровне обслуживания. Это должно являться консенсусом между исполняемыми ролями системы центра обслуживания и ожиданиями пользователей. Если какие-либо элементы соглашения об уровне обслуживания не воспринимаются однозначно, это должно быть переформулировано с привлечением персонала технической поддержки. Без консенсуса с вашим персоналом технической поддержки (непосредственными исполнителями), соглашение об уровне обслуживания не будет выполняться фактически. Элементы соглашения об уровне обслуживания. Соглашение об уровне обслуживания, как правило, состоит из следующих элементов: Границы договора. Описывает, каким образом будет использоваться соглашение об уровне обслуживания вашей организацией и пользователями. Описание. Описывает сервисы, включённые в соглашение об уровне обслуживания. Пользовательское окружение. Описывает, кто использует сервисы и как они используются. Уведомление об изменении статуса сервиса. Описывает, как статус сервиса связан с пользователями сервиса. Влияние на бизнес. Описывает влияние на бизнес, если время отклика или доступность сервисов будут нарушены. Это влияние может включать в себя стоимость труда пользователей сервиса, потерю работоспособности пользователей, упущенные выгоды, снижение доходов, потеря репутации и пр. Эти стоимости, по возможности, желательно указывать в финансовом исчислении. 128 Измерение. Описывает необходимые для выполнения действия для контроля времени реакции на обращения. Единственным путём выполнения данного контроля, является периодический анализ времени реакции. Отчёт по оценке соответствия договору обслуживания позволяет вашей организации и пользователям исчисляемый ответ на успешность или неуспешность выполнения требований соглашения об уровне обслуживания. Данные отчёты также могут быть полезны менеджерам проблем и изменений для обнаружения потенциальных проблем и инцидентов до их возникновения. Имея на руках конкретные показатели производительности, вы можете обозначить направления улучшения качества предоставляемых услуг, а также уменьшить стоимость сопровождения. Оценка соответствия соглашению об уровне обслуживания. Проведение оценки соответствия соглашению об уровне обслуживания является одним из ключевых элементов процесса управления уровнем обслуживания. Система центра обслуживания предоставляет средства для обеспечения данных действий. Менеджеры уровня обслуживания могут выполнять следующие действия: Определять метрики системы центра обслуживания для выполнения типа производимой оценки производительности. Вы можете измерять доступность сервиса, данные анализа производительности, производительность планирования. Регистрировать ключевые параметры производительности (KPI) в каждом соглашении об уровне обслуживания. Например, соглашение может описывать минимальную доступность сервиса как 95% доступности в часы обслуживания, с минимальным MTBF (Mean Time Between Failure) в 5 часов. Планирование генерации отчётов оценки соответствия соглашению об уровне обслуживания. Генерировать промежуточные отчёты оценки соответствия соглашению об уровне обслуживания. Использовать отрицательные индикаторы включённые в промежуточные или финальные отчёты для исследования событий, уменьшающих производительность уровня обслуживания. Внутренняя и внешняя оценка. Оценочный отчёт может быть использован двумя различными путями, в зависимости от типа сервиса, описываемого в соглашении об уровне обслуживания (бизнес-сервис, сервис операционного управления, подпирающий сервис). Бизнес-сервисы могут быть оценены для предоставления бизнес-пользователям, с целью информирования насколько качественно организация предоставляет бизнес-сервисы пользователям. Сервисы операционного управления и подпирающие сервисы могут быть оценены для индикации насколько эффективно и качественно поставщики услуг предоставляют сервисы. 129 Типы оценки производительности. Может быть сгенерировано несколько оценочных типов. Доступность сервиса. Данный отчёт измеряет производительность следующие аспекты доступности сервисов: Количество времени, в течении которого сервис был доступен, отображается как процент от общего времени. Доступность может быть рассчитана на основе расписания поддержки или календарном времени (которое не зависит от расписания поддержки). Подразумеваемое время между отказами (MTBF), которое определяет среднее время между событиями, влекущими отказ сервиса. Количество событий (обращений или инцидентов) зарегистрированных во время периода оценки. Количество событий, с влиянием эквивалентным или выше кода отказа сервиса. Данные анализа производительности. Данный отчёт оценивает следующие аспекты производительности возможностей обслуживающей организации по анализу событий: Среднее время реакции измеряет среднее время, необходимое обслуживающей организации для начала работ по решению обращения или инцидента. Среднее время предоставления решения измеряет среднее время, необходимое для обслуживающей организации решения инцидентов и обращений. Производительность планирования. Данный отчёт оценивает следующие аспекты обслуживающей организации по возможностям планирования разрешения событий: Количество обращений за период времени измеряет количество зарегистрированных обращений, которые не разрешены в течение планируемого промежутка времени. Количество обращений, которые превысили максимальное время разрешения, измеряет количество зарегистрированных обращений, которые не разрешены в течение максимально отведённого промежутка времени (крайний срок). Учёт запасов производительности сервисов. Если вы определяете иерархию сервисов, которая содержит сервисы операционного управления (и, возможно, подпирающие сервисы), а также, возможно, содержит бизнес-сервисы, вы можете использовать функционал оценочной отчётности для определения наиболее экономически рациональных запасов производительности вашей модели поддержки. Вы достигаете этого путём достижения договорённости о значении минимальной доступности для всех задействованных сервисов. 130 Обычно, для гарантии достижения значения минимальной доступности необходимо указывать несколько заниженные значения доступности чем, обещанные вам вашим операционным управлением и поставщиком подпирающих сервисов. Чем больше разница между значениями уровней бизнес-сервисов и значениями уровней сервисов операционного управления и подпирающих сервисов, поддерживающих бизнес-сервисы, тем большим запасом производительности вы обладаете. И наоборот, чем меньше эта разница, тем меньше шансов у вашей компании выполнить обязательства по соглашению об уровне обслуживания. Идентификация зависимых ролей системы центра обслуживания. Менеджер уровня обслуживания связан со следующими ролями системы центра обслуживания: Менеджер конфигураций. Соглашения об уровнях обслуживания определяют уровень обслуживания, требуемый КЕ, управляемых менеджером конфигураций. Персонал службы технической поддержки. При регистрации обращений персоналом службы технической поддержки, система центра обслуживания уведомляет операторов центра технической поддержки о доступных уровнях обслуживания определённого сервиса. Первая линия технической поддержки, которую представляет оператор, должна быть ознакомлена с применимостью того или иного соглашения об уровне услуг. Менеджеры изменений. Менеджеры изменений должны планировать изменения инфраструктуры ИТ в рамках действующего соглашения об уровне услуг. Менеджеры проблем. При анализе обращений и инцидентов, менеджеры проблем должны учитывать действующее соглашение об уровне обслуживания. 131 12. Задачи администратора персон и организаций. Данная глава кратко описывает процесс создания, изменения и просмотра информации о персонах и организациях. Администрирование персон и организаций. Группа «Организация», расположенная в главной консоли системы центра обслуживания, является рабочей областью администратора персонала и организаций. Группа «Организация» предоставляет доступ к следующим представлениям данных: Персона. Организация. Рабочая группа. Вы можете создавать записи персон для вашего внутреннего персонала технической поддержки, контакты с внутренними и внешними организациями и заказчиками. Как только персонал проходит процедуру регистрации, менеджеры конфигураций могут идентифицировать пользователей, владельцев и администраторов конфигурационных единиц; персонал службы технической поддержки может идентифицировать инициаторов регистрируемых обращений. 132 Пользователи системы центра обслуживания могут назначать элементы отдельным персонам; инициаторы утверждения, утверждающие, и голосующие могут быть идентифицированы и т.п. Большинство организаций состоит из множества подразделений. Классифицируя записи персон по подразделениям вашей компании, вы можете оценивать производительность подразделения по количеству обращений. Также вы можете связывать персон с подразделениями. Категоризация персон и организационных структур. До непосредственного создания записей персон и организаций, вы должны определить границы ваших данных. Во-первых, вы должны рассмотреть, каким образом данные о внешних и внутренних подразделениях должна быть собраны и введены. Если вы примете решение о вводе данных по необходимости, вы должны определить персону или группу персон, ответственных за создание организационной структуры компании. Определите, какие роли системы центра обслуживания должны быть авторизованы на создание и обновление данных организационной структуры, и скоординируйте с администратором системы выдачу соответствующих полномочий. Полномочия должны выдаваться соответственно выполняемым задачам и необходимой информации, необходимой для каждой роли. До внедрения, вы должны определить согласованную номенклатурную систему для кодов поиска организаций. Удачно выбранные коды поиска, который согласованно используется для всех вводимых элементов, значительно упрощает задачи поиска в системе центра обслуживания. После того, как вы определите вашу организационную структуру, вы можете определить необходимые для заполнения атрибуты записей персон. При создании зависимостей между персонами и внешними организациями, вы должны определить политики безопасности информации, такие как телефоны и адреса электронной почты, которые, возможно, согласуются с положениями безопасности вашей компании. Например, требование информации, такой как частный телефонный номер, могут нарушать закон неприкосновенности частной информации вашей страны. И, наконец, вы должны разработать систему категоризации для различия между различными записями персон, организаций, рабочих групп. Например, если вы хотите идентифицировать контрактников отдельно от основного персонала, создавайте соответствующую категорию для ваших заказчиков. Регистрация персон и организаций. Регистрация внутреннего персонала является важной для учёта времени работы над обращениями. Например, назначая персонал, вы вводите информацию о них в КЕ, обращения и запросы, также можете планировать выполняемую ими работу и время реакции. 133 При внесении конфиденциальных данных персон и организаций не забывайте о действующем законодательстве вашей страны. Создание записи персон. При создании записи персоны, форма, аналогичная приведённой ниже, отображается в вашей консоли: Следующие поля всегда обязательны для заполнения: Код поиска. Вы должны создать систему кодов поиска, которая позволяет пользователям системы центра обслуживания осуществлять поиск элементов. Например, оператор центра технической поддержки быстрее найдёт информацию по коду поиска, состоящему из фамилии или фамилии и инициалов. Название. Поле «Название» позволяет вам регистрировать имя персоны, которое отображается, например, в карточных представлениях. Подробное имя персоны, состоящее из фамилии, имени, отчества, звания и суффикса, вводится в поле «Полное имя». 134 Создание записей организации. При создании записи организации, форма, аналогичная приведённой ниже, отображается в вашей консоли: Создание записи рабочей группы. Рабочие группы позволяют вам организовать ваших специалистов в функциональные группы. При назначении обращения для разрешения, он может быть назначен рабочей группе. Подробности рабочей группы включают в себя список участников рабочей группы. Каждый участник рабочей группы может выполнять одинаковые задачи. При определении рабочих групп, вы можете создать систему именования, которая отображает уровень экспертизы данной группы. Например, вы можете создать рабочую группу с названием «Администраторы АИИС КУЭ» и другую группу с названием «Администраторы БД». Так как персонал вашей компании может выполнять множество ролей и иметь различные специализации, один работник может входить в несколько рабочих групп. Специалисты также могут быть участниками рабочих групп, расположенных в разных странах и 135 часовых поясах. Рабочие группы, также, могут включать внешних работников, работающих на контрактной основе, и работников внутренних департаментов. При создании записи рабочей группы, форма, аналогичная приведённой ниже, отображается в вашей консоли: Рабочей группе также может быть назначен календарь. Календарь предоставляет необходимую информацию подсчёта времени при выполнении задач планирования при назначении нарядов рабочим группам. Календарь содержит Рабочее время, показывающее расписание, по которому рабочая группа оказывает обслуживание, и выходные, отображающее дни, когда рабочая группа не работает. Персоне, которая не состоит хотя бы в одной рабочей группе, невозможно назначить какой-либо из элементов системы центра обслуживания. 136 13. Использование средств электронной почты для управления данными. Данная глава проводит краткий обзор настройки интеграции средств электронной почты с системой центра обслуживания. Отправка сообщений электронной почты системе центра обслуживания. Входящей почтой называется электронная почта, отправляемая системе центра обслуживания. Система центра обслуживания может принимать электронные сообщения от любого стандартного SMTP приложения (напр. Microsoft Outlook). Информация, содержащаяся в полях (From, To, Cc и Subject) определяет, какие действия должна выполнить система центра обслуживания с входящим сообщением. Информация, содержащаяся в теле сообщения, используется для предоставления описания выполняемого действия. Электронное письмо должно быть написано в текстовом формате (plain text). Допускается использование вложений в сообщения. Входящие в тело сообщения вложения не принимаются, например, рисунки, содержащиеся в теле сообщения. Почтовым адресом принятия входящих сообщений в …, является адрес электронной почты …. В конфигурации, используемой в …, написан «шлюз» (Relay POP3>SMTP) пересылки почтовых сообщений с адреса … на SMTP сервер системы центра обслуживания с использованием языка программирования Perl. Запуск данного сценария осуществляется штатным планировщиком ОС Windows, с 5-ти минутным интервалом. С помощью входящей электронной почты можно выполнить следующие действия: Создать обращение. Изменить статус обращения. Обновить информацию поля «Решение» в обращении. Отправить запрос и получить список открытых обращений инициированных отправителем или назначенных для разрешения отправителю. Просмотреть подробности обращения. Добавить информацию аудита в обращение. Принять или отклонить решение специалиста по разрешению обращения. Отменить обращение. Запросить справочную информацию по использованию данного функционала. Обращения могут быть созданы и обновлены с помощью электронной почты. Другие элементы, такие как КЕ, Персоны и изменения не могут создаваться или изменяться с использованием электронной почты. 137 Использование входящей электронной почты. Как описывалось выше, сообщение должно быть отправлено в текстовом формате на адрес электронной почты …, сообщения допускают вложения, кроме вложений непосредственно в теле письма. Если ваш почтовый клиент использует колонтитулы, обрамите тело сообщения тэгами BEGIN и END (напр. BEGIN текст сообщения END). После того, как команда будет оправлена, сообщение с уведомлением будет выслано отправителю, что, например, обращение создано или не может быть создано с причиной отказа. Сообщения уведомлений основываются на хранимых в системе шаблонах, которые могут быть изменены по необходимости. Использование команды «New». Когда система центра обслуживания получает команду «New», создаётся новое обращение и значения по умолчанию для шаблона входящей электронной почты, который связан с почтовым адресом системы центра обслуживания, копируются в новое обращение. Для использования данной команды необходимо: Ввести адрес электронной почты … в поле «To:». При отправке используйте учётную запись электронной почты, которой есть соответствие в системе центра обслуживания, и которая будет учитываться при идентификации инициатора обращения. По поводу учётных записей электронной почты персон обращайтесь к администратору системы центра обслуживания. Введите команду «New» в поле «Subject» сообщения. Введите краткое описание обращения в поле «Subject» после команды «New». Данный текст будет скопирован в поле «Описание» обращения. Введите дополнительную информацию об обращении в тело сообщения. Текст, находящийся в теле сообщения будет скопирован в поле «Информация» обращения. Если текст является слишком длинный, он будет обрезан, и полный исходный текст сообщения будет содержаться в виде вложения в обращении. В поле «Информация» будет вставлен комментарий с предупреждением о превышении длины тела сообщения. Использование команды «Update<id>». Команда «Update<id>» может быть использована для обновления информации обращения. Все поля обращения могут быть обновлены. Для использования данной команды необходимо: В поле «Subject», ввести команду Update со следующим за ней идентификатором обращения, например Update 1234. Укажите поле, которое вы хотите обновить в теле сообщения, после чего поставьте знак «=» и укажите значение поля. Каждое поле должно начинаться с новой строки. Имена полей должны соответствовать именам полей формы обращения. 138 После выполнения команды обновления обращение выглядит следующим образом: А также инициатору отправляется уведомление по электронной почте примерно следующего содержания: Использование команды «Add History Line<id>». Когда система центра обслуживания принимает команду «Add History Line<id>», содержание тела письма копируется в новую запись аудита. Если текст является слишком длинным, он усекается, исходный полный текст сообщения прикрепляется вложением, и в 139 записи аудита добавляется комментарий о предупреждении усечения текста. Для использования этой команды введите в поле «Subject» команду «Add History Line» со следующим за ним идентификатором сообщения, например, Add History Line 1234. Сочетание «[?]» представляет собой жёстко запрограммированную переменную, в данном случае «[?]» будет заменён информацией из поля записи аудита. Использование команды «View <id>». Когда система центра обслуживания получает команду «View <id>», сообщение, содержащее подробности обращения с заданным в параметрах команды идентификатором, будет выслано отправителю. Для использования данной команды в поле сообщения «Subject» необходимо ввести команду «View», со следующим за ним идентификатором обращения. Например, View 1234. В ответ будут высланы значения всех основных атрибутов обращения с заданным идентификатором. Использование команды «List». Когда система центра обслуживания получает команду «List», система отправляет сообщение отправителю, содержащее список всех открытых обращений назначенных отправителю и все открытые обращения, инициированные отправителем. Также включается в сообщение идентификатор обращения и описание. Обращение считается открытым, если поле «Факт. окончание» (Фактическое окончание) не содержит значение. Для использования данной команды укажите в поле «Subject» сообщения команду «List». Использование команды «RE:RFI<id>». Команда «RE:RFI<id>» служит для добавления дополнительной информации аудита в обращение. Когда система центра обслуживания получает команду «RE:RFI<id>», запись аудита добавляется в обращение указанного идентификатора. Статус обращения при этом меняется, например, на «Получена дополнительная информация». Для использования данной команды, введите в поле «Subject» сообщения команду «RE:RFI<id>», например, RE:RFI 1234. Сочетание символов «[?]» в данном случае, является жёстко запрограммированной переменной, являющейся переменной записи аудита. Использование команды «RE:Solution Accepted <id>». Когда система центра обслуживания получает команду «RE:Solution Accepted <id>», это изменяет статус обращения на статус указанный в команде, решение принято, например. 140 Для принятия предлагаемого решения по разрешению обращения, в поле «Subject» сообщения укажите команду «RE:Solution Accepted <id>». Использование команды «RE:Solution Rejected <id>». Когда система центра обслуживания получает команду «RE:Solution Rejected <id>», это изменяет статус обращения на статус указанный в команде, решение отклонено, например. Для отклонения предлагаемого решения по разрешению обращения, в поле «Subject» сообщения укажите команду «RE:Solution Rejected <id>». Использование команды «Recall <id>». Команда «Recall <id>» используется для отзыва обращения. Обращение, в данном случае, не удаляется из базы данных системы центра обслуживания. Статус обращения меняется на определённый статус, «Отменён», например. Для использования данной команды в поле «Subject» сообщения укажите команду «Recall <id>». Использование команды «Help». Когда система центра обслуживания получает команду «Help», будет послано электронное сообщение, персоне, указанной в поле «From:» сообщения, содержащее краткий перечень доступных команд электронной почты и краткое описание каждой из них. Текст данного сообщения может быть изменён администратором системы. Для использования данной команды в поле «Subject» сообщения укажите команду «Help». 141
