Основные процессы и принципы работы службы «Service Desk» Содержание Термины и сокращения документа ..................................................................................................... 1 Наименование и область применения документа ............................................................................... 3 Основание для разработки ................................................................................................................ 3 Цель создания службы Service Desk на Фирме.................................................................................... 3 Процессный подход ........................................................................................................................... 4 Управление ИТ-сервисами (ITSM) ...................................................................................................... 5 Задачи Service Desk ........................................................................................................................... 7 Схема и структура работы Service Desk .............................................................................................. 8 Основная Терминология .................................................................................................................. 10 Основные процессы службы Service Desk ......................................................................................... 12 Управление Инцидентами ........................................................................................................ 12 Управление Проблемами ......................................................................................................... 13 Роли и ответственность сотрудников Service Desk ............................................................................ 14 Менеджер................................................................................................................................ 15 Аналитик (инженер, диспетчер) .............................................................................................. 15 Отчетность Service Desk .................................................................................................................. 16 Service Level Agreement ................................................................................................................... 17 Управление Инцидентами (детальное описание) .............................................................................. 18 Категория................................................................................................................................ 21 Приоритет ............................................................................................................................... 22 Услуги (сервисы) ..................................................................................................................... 22 Группа поддержки ................................................................................................................... 22 Сроки решения ........................................................................................................................ 22 Идентификационный номер инцидента .................................................................................... 22 Статус ..................................................................................................................................... 23 Привязка (сопоставление) ....................................................................................................... 23 Расследование и диагностика .................................................................................................. 23 Решение и восстановление ...................................................................................................... 23 Закрытие ................................................................................................................................. 23 Мониторинг хода решения и отслеживание.............................................................................. 24 Возможные проблемы ............................................................................................................. 24 Управление Проблемами (детальное описание) ............................................................................... 24 Контроль проблем .................................................................................................................. 27 Контроль ошибок .................................................................................................................... 27 Приложение 1. Перечень Процессов ITSM ...................................................................................... 29 Приложение 2. Схема организации идеальной службы Service Desk ................................................ 30 Приложение 3. Основные процессы (workflow) Service Desk ............................................................ 31 Приложение 4. Основные преимущества Service Desk .................................................................... 32 Приложение 5. Примерный план внедрения Help Desk .................................................................... 33 Термины и сокращения документа Термин Фирма Workflow FrameWork Процесс Описание ELEKS Software, Ltd. - professional software development company Производственный, рабочий процесс или последовательность процедур, через которые проходит определенное изделие, задание, документ и т. д. с момента начала и до момента окончания работ. Кратко поток заданий Cтруктурированная основа для организации Процессов Логически взаимосвязанная между собой последовательность работ (видов деятельности), направленная на достижение поставленной цели. Service Desk (main process) 21.09.2007 (версия 1.1) 1 Процедура Описание логически связанных видов работ с указанием их исполнителей. Процедура может включать в себя этапы из различных процессов. Процедура определяет, что должно выполнятся и кем, и она может меняться в зависимости от организации. ITIL Information Technology Infrastructure Library - набор передовых методов управления службами ИТ, разрабатывался правительством Великобритании для улучшения процессов управления службами ИТ и признан отраслевым стандартом во всем мире. ITIL, хоть и включает в себя ITSM, описывает не только управление услугами, но и сопутствующие процессы. ITIL, ITSM is a Registered Trade Mark, and a Registered Community Trade Mark of the Office of Government Commerce, and is registered in the U.S. Patent and Trademark Office. IT Infrastructure Library is a Registered Trade Mark of the Office of Government Commerce ITSM IT Service Management, управление IT услугами — подмножество библиотеки ITIL, описывающее процессный подход к предоставлению и поддержке IT услуг. В отличие от традиционного технологического подхода, ITSM рекомендует сосредоточиться на клиенте и его потребностях, на услугах, предоставляемых пользователю информационными технологиями, а не на них самих. Help Desk Отдельное подразделение, которое решает вопросы по приему и обработки запросов пользователей, подразумевает функции начальной технической поддержки. В отличии от Service Desk, Help Desk участвует только в одном процессе - Управление Инцидентами. Service Desk Более широкое понятие, чем Help Desk, подразумевает функции приема и обработки обращений от пользователей по различным вопросам, связанным с ИТ: Инцидентов, запросов на обслуживание, жалоб, запросов на изменения, а также их последующий анализ и интерпретацию. Далее по тексту документа под сочетанием «Service Desk» либо «Служба» или «Служба поддержки» подразумевается именно отдельная служба Service Desk. Call Center Организационное подразделение (возможно даже стороння фирма), которое направлено на прием и диспетчеризацию большого объема телефонных обращений. Основная задача - это регистрация и дальнейшая диспетчеризация звонков, не подразумевает какую-либо обработку обращений и принятие решений. База знаний Knowledge Base, KB - это специальная база данных (а возможно и отдельное программное обеспечение), разработанная для управления знаниями (метаданными), сбором, хранением, поиском и выдачей информации по решению Инцидентов (Знаний) SLA Service Level Agreement (Соглашения об уровне обслуживания), документ, в котором предъявляются требования к основным измеряемым характеристикам услуги или Сервиса Инцидент Любое событие, которое привело или может привести к приостановке нормальной работы сервиса или снижение качества работы этого сервиса. Если запрос не является Инцидентом, то он рассматривается как Запрос сервиса. Проблема Неизвестная причина возникновения одного или нескольких Инцидентов. Когда причина появления Инцидентов найдена, Проблема превращается в известную ошибку Service request Запрос на Обслуживание (Запрос Сервиса или просто Запрос) обращение от Пользователя на поддержку, предоставление информации, консультации или документации, не являющийся Инцидентом RFC Request For Change (RFC) Запрос на Изменение, это экранная или бумажная форма, используемая для записи детальной информации о предлагаемом Запросе на изменение чего-либо в ИТ-инфраструктуре или процедуры Эскалация WorkAround Переход поиска решения Инцидента на очередной уровень службы Service Desk Временное решение, т.е. применимое для разрешения Инцидентов до устранения корневой причины путем внесения изменений в инфраструктуру Service Desk (main process) 21.09.2007 (версия 1.1) 2 Конфигурацион ная база данных CMDB База данных, содержащая информацию о характеристиках компонентов ИТ инфраструктуры предприятия и взаимосвязях между этими компонентами, которая может быть использована в процессе предоставления услуг. То же самое что и Конфигурационная база данных CI Конфигурационная Единица ИТ Информационная технология KPI Key Performance Indicator Ключевой Показатель Качества работы Сервиса или Сети ПО Программное Обеспечение ПС Программное Средства, то же что и ПО Система ZZ Программное обеспечение, которое позволяет автоматизировать основные процессы, происходящие в Service Desk резерв Термины и аббревиатуры, которые не указаны в таблице, но встречаются в тексте, являются общеизвестными в ИТ-области терминами или взяты из библиотеки ITIL. Для исключения разночтений, все сокращения и термины используются в документе с Заглавной Буквы. Наименование и область применения документа Изложение основной методологии и работы службы Service Desk, описание базовых принципов работы и требований к организации основного Workflow этой службы. Служба будет внедряться в головном офисе Фирмы. Полное наименование документа Описание основных процессов и принципов работы службы Service Desk Фирмы. Основание для разработки Распоряжение директора по производству Фирмы. Документ необходимо разработать на базе лучших мировых практик и методологий используемых в отрасли информационных технологий. Цель создания службы Service Desk на Фирме Создание на Фирме центральной службы технической поддержки для клиентов Фирмы. Service Desk должен решать и предотвращать проблемы клиентов Фирмы с программным обеспечением для максимального удовлетворения их требований. Service Desk (main process) 21.09.2007 (версия 1.1) 3 Процессный подход Каждая организация нацелена на выполнение своих корпоративных целей и миссии, решение стратегических задач и реализацию выбранной политики. Это достигается через выполнение определенной деятельности. Необходимо структурировать работы, которые направлены на достижение поставленной цели, то есть организовать их таким образом, чтобы было видно, как каждая группа работ способствует решению стратегических задач и как эти группы связаны между собой. Такие группы организованной между собой деятельности называются процессами. В случае, если процессная структура организации четко определена, то она дает ответы на вопросы: 1. Что должно быть сделано. 2. Какой ожидается результат. 3. Каким образом можно определить (измерить), что в результате работы процесса достигается ожидаемый результат. 4. Как результаты выполнения одного процесса влияют на результаты других процессов. Вопросы, представленные на рис. 1а постоянно возникают при использовании процессного подхода, типичного для современного ИТ предприятия. Средства для нахождения ответов на них приведены в правой части рисунка. Рис.1а Модель совершенствования процессов При организации работ в виде процессов не учитываются ни существующее распределение работ, ни деление Фирмы на отделы. Это сознательный выбор. Делая выбор в пользу процессной структуры, можно доказать, что некоторые виды работ на Фирме не координируются, дублируют друг друга, игнорируются или вообще не нужны. Вместо этого мы сосредотачиваемся на цели процесса и его взаимоотношениях с другими процессами. Процесс — это последовательность работ, нацеленная на преобразование входных данных Service Desk (main process) 21.09.2007 (версия 1.1) 4 (информации, документации и т. д.) в выходные. Для получения информации о том, каким будет результат выполнения процесса, нужно проверить вход и выход каждого процесса на соответствие характеристикам качества и стандартам. В результате этого получаются цепочки процессов, по которым можно отследить, что происходит в организации и какой результат получается, а также определить контрольные точки в этих цепочках, в которых выполняется мониторинг качества продуктов и услуг, предоставляемых организацией. Стандарты для выходных данных каждого процесса должны быть определены таким образом, чтобы вся цепочка процессов обеспечивала достижение корпоративных стратегических целей. Если результат процесса отвечает заданному стандарту, такой процесс будет считаться эффективным (effective). Если работы в рамках данного процесса к тому же выполняются с наименьшими усилиями и затратами, этот процесс будет рациональным (efficient)1. Цель Управления Процессами — планировать и контролировать процессы таким образом, чтобы они были одновременно эффективными и рациональными. Для оптимизации качества процессов каждый из них можно рассматривать отдельно. Владелец процесса несет ответственность за результаты работы процесса. Менеджер процесса отвечает за его структуру и выполнение и подотчетен владельцу процесса. Координаторы процесса отвечают за выполнение заданных видов работ и отчитываются о их результатах выполнения менеджеру процесса. Логическая структуризация работ внутри процесса позволяет установить четкие точки перехода, в которых есть возможность выполнять мониторинг качества процесса. Руководство организации может осуществлять контроль, основываясь на информации о качестве каждого из процессов. В большинстве случаев соответствующие показатели эффективности и стандарты уже будут предопределены Соглашениями. Поэтому каждодневный контроль процесса передается Руководителю (менеджеру) Процесса. Владелец процесса будет оценивать работу по показателям производительности и их соответствию согласованному стандарту. Без четких показателей владельцу процесса будет трудно определить степень контролируемости процесса и реализации запланированных улучшений. Управление ИТ-сервисами (ITSM) Для многих ИТ-организаций синонимом эффективности становится сегодня модель функционирования, основанная на основе библиотеки ITIL, которая систематизирует лучшие практики работы ИТ-департаментов, помогая сформулировать цели ИТ подразделений, задать параметры измерения прогресса в достижении этих целей, оценить результаты и определить возможные действия в случае, когда они оказываются 1 Суть терминов «effective» и «efficient» можно также проиллюстрировать выражениями «делать правильные вещи» и «делать вещи правильно». Service Desk (main process) 21.09.2007 (версия 1.1) 5 несоответствующими поставленным целям. Процессы и сервисы, краеугольные камни модели ITIL. Согласно построенной на базе ITIL методологии управления ИТ-сервисами (ITSM), ИТ департамент превращается в сервисное подразделение, предоставляющее свои услуги бизнесу. Цель процессов ИТ Сервис-менеджмента — содействовать повышению качества ИТ услуг. Управление Качеством и контроль процессов являются частью организации и ее политики. Предоставление нужных сервисов надлежащего качества в ITIL/ITSM базируется на процессной организации работы Службы. Центральными для модели ITIL/ITSM являются две группы процессов (см. рис. 1), обеспечивающие поддержку услуг и их предоставление. Процессы группы поддержки сервисов называют также оперативными, поскольку они включают в себя повседневные функции информационного департамента, обеспечивающие реализацию ИТ-сервисов. Процессы второй группы относят к тактическим процессам, гарантирующим предоставление услуг с заданным качеством. Для решения основной задачи данного документа, нас будет интересовать вопросы, относящиеся к Поддержке сервисов. Рис.1 Основные группы процессов ITIL/ITSM Методология ITSM сосредоточена в двух книгах ITIL (два тома): «Поддержка сервисов» («Service Support») и «Предоставление сервисов» («Service Delivery»), которые состоят из следующих 10 частей (глав), смотрите Таблицу 2. Традиционная основа службы поддержки — процесс управления инцидентами — превращается в ключевого поставщика информации для остальных четырех оперативных процессов: управления проблемами, изменениями, релизами и конфигурациями. Для решения цели этого документа есть смысл сосредоточить свое внимание в основном на процессах управления Инцидентами и Проблемами. Наглядное и подробное отображение идеальной схемы Service Desk (с указанием соответствующих Процессов) можно найти в Приложении №2. Service Desk (main process) 21.09.2007 (версия 1.1) 6 Таблица 2 Перечень Процессов ITSM Процессы Поддержка сервисов (Service Support) 1 Управления инцидентами (Incident Management) 2 Управления проблемами (Problem Management) 3 Управления конфигурациями (Configuration Management) 4 Управления изменениями (Change Management) 5 Управления релизами (Release Management) Процессы Предоставление сервисов (Service Delivery) 1 Управления уровнем услуг (Service Level Management) 2 Управления финансами (Financial Management for IT Services) 3 Управления мощностью (Capacity Management) 4 Управления непрерывностью (IT Service Continuity Management) 5 Управления доступностью (Availability Management) Краткое описание других процессов смотрите в Приложении №1. Задачи Service Desk Service Desk должен быть - единой точкой контакта между клиентами (пользователями) и ИТ специалистами, от приема обращений, до оказания квалифицированной технической поддержки. Ключевые задачи Службы указаны в таблице 1. Таблица 1 Основные операции Service Desk № Наименование операций 1 Прием, регистрация обращений пользователей по вопросам ИТ 2 Идентификация и обработка Инцидентов и запросов на обслуживание 3 Накопление базы знаний по решенным инцидентам 4 Управление жизненным циклом Инцидента 5 Информирование пользователей о текущем статусе обращений 6 Контроль сроков решения инцидентов 7 Диспетчеризация инцидентов специалистам более высокой квалификации 8 Информирование пользователей о проведении плановых работ, изменений и т.д. Service Desk обеспечивает: 1. Единую точку контакта к службе поддержки. Удобный и понятный для клиентов механизм позволит более быстро решать их проблемы. 2. Стандартный способ регистрации и выдачи заданий специалистам. 3. Контроль над последовательностью выполненных работ, потраченного времени и ресурсов. 4. Назначение приоритетов запросам в зависимости от типа запроса, конкретного клиента или других обстоятельств. 5. Хранение базы знаний по прошлым запросам, позволяющее специалистам быстро решать проблемы, схожие с уже возникавшими. Service Desk (main process) 21.09.2007 (версия 1.1) 7 Схема и структура работы Service Desk В общем случае работа Service Desk может быть представлена из пяти основных этапов, которые показаны на рис.2 (или более подробно в Приложении №3). 1. Пользователь обращается в Службу с заявкой о Проблеме (Инциденте). 2. Оператор выполняет анализ заявки, и присваивает ей Категорию, при возможности помогает пользователю решить проблему с помощью Базы Знаний. 3. Координатор назначает Инженера для решения заявки и фиксирует ее закрытие. 4. Инженер решает проблему либо возвращает ее координатору. 5. Выполняются работы по извещению пользователя. Рис.2 Основная схема работы Service Desk Структура Service Desk напоминает луковицу (рис. 3). Ее сердцевина — программно аппаратный комплекс, называемый центром обработки вызовов, который обеспечивает грамотное распределение заявок. Например, для этих целей может применяться решение IP Contact Center компании Cisco Systems. Вокруг него строится Help Desk, который отличается от Service Desk тем, что участвует только в одном процессе — в управлении инцидентами. Соответственно, задачи Help Desk — зарегистрировать инцидент и как можно быстрее восстановить нормальную работу сервиса самостоятельно либо привлечь группу специалистов более высокого уровня для полного устранения причины инцидента. Но мы должны не только «тушить пожары», но и предупреждать их. Мы должны оказывать бизнесу дополнительные услуги и именно этим и занимается Service Desk, как структурное подразделение. Service Desk (main process) 21.09.2007 (версия 1.1) 8 Рис.3 Структура Service Desk Техническая поддержка, как процесс, может иметь несколько уровней, но обычно их три. Первый уровень — это сама центральная служба технической поддержки, она же Service Desk. Сюда со своими проблемами обращаются все пользователи, и попытки обратиться напрямую к инженерам пресекаются. Это нужно, чтобы не отвлекать высококвалифицированных специалистов на решение простых задач. Второй уровень поддержки — так называемые технические специалисты, которые владеют глубокими знаниями по определенным технологическим направлениям, например, по SQL серверу или очень хорошо разбираются в работе веб-серверов. Третьим уровнем может быть, группа разработчиков, которая не просто поддерживает продукт, но и дорабатывает его в соответствии с меняющимися запросами бизнеса. К этому же уровню можно отнести и специалистов внешних компаний — поставщиков технологий и услуг. Переход Инцидента на очередной уровень технической поддержки (Эскалация) означает увеличение времени и стоимости его разрешения. Разумеется, следует стремиться к тому, чтобы больше Инцидентов решать уже на первом уровне, где специалисты хотя и квалифицированные, но значительно более дешевые, чем, на третьем уровне. Схема маршрутизации Инцидента, показана на рисунке 4, стоит отметить, что на рисунке показана Функциональная эскалация (горизонтальная). Подробнее об Эскалации, смотрите раздел «Основная Терминология». Service Desk (main process) 21.09.2007 (версия 1.1) 9 Рис.4 Уровни поддержки Service Desk Основная Терминология Для понимания процессов работы Службы, определимся с основными терминами и их трактовкой, которая в разных источниках отличается. В ITIL все обращения (Запросы) могут регистрироваться и отслеживаться, как Инциденты. Однако более правильным будет следующая градация, когда под Проблемой подразумевается событие, которое может привести к остановке нормальной работы Сервиса либо значительно ухудшить качество работы этого сервиса. Под Инцидентом, подразумевается более критические события, в работе вышеупомянутого Сервиса (выходящее за рамки допустимых величин), когда для восстановления его работы (либо качества) требует значительное время. Запрос на обработку Инцидентов – запрос от пользователя в Service Desk, к таким запросам можно отнести все запросы, как о Проблемах, так и об Инцидентах. Service Desk (main process) 21.09.2007 (версия 1.1) 10 Запрос на Обслуживание (Service Request) – это запрос от пользователя на предоставление информации, консультации или документации, не являющийся Запросом о Проблеме. Примеры Запросов на обслуживание: • запрос о функционировании или предоставлении информации о работе ПС; • запрос о возможности работы ПС на новом «железе». Для того чтобы можно было отличить Инциденты от «Инцидентов-Запросов на Обслуживание», рекомендуется присваивать Запросам на Обслуживание специальную категорию. Важно также отметить, что Запрос на Обслуживание это не то же самое, что Запрос на Изменение. Запрос на Изменение (RFC) — это устное обращение или экранная (бумажная форма), используемая для записи детальной информации о предлагаемом запросе на изменение каких-либо характеристик ПС либо в ИТ инфраструктуре. Запрос RFC считается завершенным после проведения изменения в инфраструктуре, например, замены зарегистрированных компонентов, инсталляции ПК и т. д. Это не Инциденты, а изменения. При одновременной обработке нескольких Инцидентов необходимо расставлять приоритеты. Обоснованием для назначения приоритета служит уровень важности ошибки для бизнеса и для клиента. На основе диалога с пользователем и в соответствии с положениями SLA, Служба назначает приоритеты, определяющие порядок обработки Инцидентов. При эскалации инцидентов на вторую, третью или более линии поддержки, тот же приоритет должен быть соблюден, но иногда он может быть скорректирован по согласованию со Службой. Каждый пользователь будет считать, что его Инцидент имеет наивысший приоритет, но мнения пользователей часто бывают субъективными. Для объективной оценки приоритета в диалоге с пользователем употребляются следующие критерии: 1. степень воздействия инцидента: степень отклонения от нормального уровня предоставления услуги, выражающаяся в количестве пользователей или бизнес процессов, подвергшихся воздействию Инцидента; 2. срочность инцидента: приемлемая задержка разрешения Инцидента для клиента или бизнес процесса. Приоритет определяется на основе срочности и степени воздействия. Для каждого приоритета определяется количество специалистов и объем ресурсов, которые могут быть направлены на разрешение Инцидента. Порядок обработки инцидентов одинакового приоритета может быть определен в соответствии с усилиями, необходимыми для Service Desk (main process) 21.09.2007 (версия 1.1) 11 разрешения инцидента. Например, легко разрешаемый инцидент может быть обработан перед инцидентом, требующим больших усилий. Степень воздействия и срочность также могут сами меняться во времени, например, при росте количества пользователей, подвергшихся воздействию инцидента или в критические моменты времени. Если инцидент не может быть разрешен первой линией поддержки за согласованное время, необходимо привлечение дополнительных знаний или полномочий. Это называется Эскалацией, которая происходит в соответствии с рассмотренными выше приоритетами и, соответственно, временем разрешения инцидента. Различают функциональную и иерархическую эскалацию: ③ Функциональная эскалация (горизонтальная) - это передача Инцидента на вторую линию поддержки при невозможности устранения инцидента на первой (привлечение большего количества специалистов). При функциональной эскалации растет и качество вовлекаемых ресурсов. ③ Иерархическая эскалация (вертикальная) — означает переход на более высокий уровень, в рамках организации, так как для разрешения инцидента недостаточно организационных полномочий (уровня власти) или ресурсов. Она становится необходимой при невозможности устранения инцидента либо за выделенное время, либо с необходимым качеством. В отличие от функциональной эскалации, иерархическая эскалация привлекает внимание руководства. Основные процессы службы Service Desk Согласно методологии ITISM основными процессами для Service Desk(a) являются: Процесс Управления инцидентами (Incident Management) и Процесс Управления проблемами (Problem Management). Основная цель процесса Управления Инцидентами — скорейшее восстановление нормального функционирования сервиса в соответствии с Соглашением об уровне услуг и минимизация воздействия отказа на жизнедеятельность бизнеса. Основная цель процесса Управления проблемами — сделать так, чтобы Инцидентов стало меньше, что достигается за счет выявления и устранения их причин. Управление Инцидентами Этот процесс носит реактивный характер (фиксация и разрешения Инцидентов). Его часто связывают со службой Help Desk. Он направлен на быстрое восстановление обслуживания путем устранения неполадок, возникающих в инфраструктуре либо в работе ПС. Задача процесса Управления Инцидентами - свести к минимуму случаи прерывания обслуживания Service Desk (main process) 21.09.2007 (версия 1.1) 12 или прерывания в работе сервиса. Он играет роль повседневного интерфейса общения между клиентами и Фирмой, что делает его необходимым для успешного управления удовлетворенностью клиентов. Процесс можно охарактеризовать как сочетание обработки обращений и эффективной поддержки первого, второго и третьего уровней. Разграничение между Инцидентами и Проблемами иногда может запутывать, но его главное отличие заключается в установлении различия между быстрым восстановлением услуги и установлением причины инцидента и ее устранением. Все Инциденты регистрируются, причем качество регистрационной информации определяет эффективность ряда других процессов. Типовой перечень задач, относящийся к Управлению Инцидентами, и методы контроля качества его работы указаны в Таблице №3. Таблица 3 Деятельность по Управлению Инцидентами Реализация Контроль качества Прием обращений Разработка структуры Службы Помощи Регистрация инцидента Создание системы контроля и различной Эскалация инцидента регламентирующей документации Службы Помощи Классификация инцидентов Отслеживание истории инцидентов Определение приоритетов Изоляция неполадок Удаление неполадок Составление административных отчетов Уведомление клиентов Непрерывное совершенствование процесса Закрытие дела Управление Проблемами Этот процесс носит превентивный или проактивный характер (позволяющий анализировать ситуацию и предотвращать проблемы еще до их возникновения). Он направлен на снижение числа неполадок производственной среды и реализуется путем изучения источников их возникновения (на основе информации о прошлых Инцидентах). Он также включает анализ тенденций и контроль известных ошибок с расчетом на устранение их источников в долговременной перспективе, а также информирует другие процессы о потенциальных проблемах в инфраструктуре и работе сервисов. Когда причины установлены (определены источники ошибки), принимается бизнес-решение о том, необходимо ли делать улучшения в инфраструктуре, в программном обеспечении для предотвращения возникновения новых инцидентов. Такие улучшения производятся путем подачи Запросов на Изменение (RFC). Service Desk (main process) 21.09.2007 (версия 1.1) 13 Процесс Управления Инцидентами начинает действовать с появлением Инцидента и прекращает свою работу после исправления ситуации. Это означает, что корневая причина возникновения инцидента не всегда бывает установлена и инцидент может повториться снова. Для выяснения корневых причин возникновения как существующих, так и потенциальных ошибок в предоставлении услуг, в рамках Процесса Управления Проблемами производится изучение инфраструктуры и имеющихся регистрационных данных, включая базу данных инцидентов. Такие исследования необходимы из-за сложного и распределенного характера инфраструктуры, когда связи между инцидентами не всегда бывают очевидными. Например, причиной проблемы могут стать сразу несколько ошибок, и в то же время несколько проблем могут быть связаны с одной и той же ошибкой. Вначале надо определить причину возникновения проблемы. После того, как корневая причина определена, проблема переходит в разряд известных ошибок и для устранения этой причины можно направить Запрос на Изменение. Но даже после этого известные ошибки будут отслеживаться и контролироваться в рамках Процесса Управления Проблемами. Поэтому следует вести регистрацию всех идентифицированных известных ошибок, их симптомов и имеющихся решений. Таблица 4 Деятельность по Управлению Проблемами Реализация Контроль качества Анализ тенденций в Создание системы контроля проблем/известных возникновении проблем ошибок Создание превентивных процедур Регистрация проблем технического обслуживания Отслеживание истории Разработка методов анализа известных ошибок проблем Решение проблем Выявление источника Создание интерфейсов поддержки Анализ известных ошибок поставщиков Установка и поддержание Контроль известных ошибок контактов поддержки Закрытие дел по проблемам Составление административных отчетов и известным ошибкам Непрерывное совершенствование процесса Обратите внимание, что информация в колонках, размещенная в таблицах 3 и 4 сгруппирована для компактности предоставления информации и не имеет никакой связи по строкам. Роли и ответственность сотрудников Service Desk Для распределения обязанностей (ролей) сотрудников службы поддержки, необходимо учитывать размер организации и основные соглашения уровня обслуживания (SLA), между Service Desk и бизнесом. Важно помнить, что речь идет об описании ролей, а не позиций. Service Desk (main process) 21.09.2007 (версия 1.1) 14 Для решения задач Службы необходимо выделить следующие роли: • Менеджер службы поддержки. • Аналитик службы поддержки. Менеджер У менеджера Service Desk, большинство задач связанны с координацией работы всей Службы и его непрерывного развития. Основные задачи для него указаны далее: • Управление ежедневными действиями и аналитиками Службы, оценка работы. • Мониторинг эффективности работы и составление рекомендаций по ее совершенствованию. • Создание и поддержание планов подготовки сотрудников. • Выработка управляющей отчетности. • Поддержание процессов, используемых в пределах Службы и развитие новых. • Создание культуры обслуживания в пределах Службы. Аналитик (инженер, диспетчер) Роль аналитика Service Desk ответственна за выполнение ежедневных задач и процессов Службы. Эта роль, прежде всего, связана с выполнением процесса Управления Инцидентами. В первые моменты цикла жизни Инцидента, аналитики Service Desk ответственны за корректную регистрацию и классификацию Инцидента, оказание начальной поддержки. На стадии начальной поддержки, они ответственны за разрешение максимального количества Инцидентов, насколько это возможно в пределах определенных временных рамок. Эти действия напрямую связанны с удовлетворением клиента и определяют дальнейшую судьбу Инцидента в цепи поддержки. Аналитики Службы ответственны за назначение Инцидентов, которые не были решены сразу. Однако их ответственность на этом не заканчивается, они продолжают сохранять ответственность за Инцидент, чтобы гарантировать, что они продолжают обрабатываться в соответствии с целями обслуживания, он также информирует клиента о прогрессе работ в течение всей жизни Инцидента. Как только Инцидент разрешен, аналитик должен убедиться, что клиент удовлетворен решением, и только потом закрыть инцидент. Эта роль также включает начальную обработку всех типов Запросов, поступающих в Service Desk и обслуживания таких внутренних элементов инфраструктуры Service Desk(a), как, например, пополнение базы Knowledge Base или пополнение списка Часто Задаваемых Вопросов. Эта роль ответственна за следующие действия: • Регистрация инцидента. • Направление запросов в группы решения, в случае если инциденты не разрешены во время начальной поддержки. Service Desk (main process) 21.09.2007 (версия 1.1) 15 • Начальная поддержка и классификация. • Контроль статуса и продвижения по разрешению всех открытых инцидентов. • Информирование пользователей о продвижении запросов. • Эскалация Инцидента в случае необходимости. • Для аналитика главнейшим качеством является способность работать в условиях постоянного стресса, умение «держать удар», конструктивно подходить к решению задач, корректно отвечать на претензии и обвинения фразой «Понимаю, что Вам сейчас тяжело, у Вас большая проблема, помогите мне, чтобы я смог помочь Вам...». Это то, что называется ассертивностью — уверенная настойчивость, способность из всего потока «негатива» выделить полезную информацию, использовать ее, не принимая негатив близко к сердцу. • Второе необходимое качество — это умение работать в команде. Нужны не «звезды», а люди, которые могли бы работать вместе. • Третьим из важнейших личных качеств является дисциплинированность, чтобы у всех, кто связан с человеком по работе, была уверенность в том, что он придет в нужное время и займется своим делом. • Четвертое качество — эрудиция, умение получать информацию по большому количеству продуктов, и самое главное — желание это делать, у него должны быть обширные, не обязательно глубокие знания почти во всех областях информационных технологий. Он должен иметь представление о часто задаваемых вопросах, знать, что есть группы специалистов на втором уровне, у которых можно получить консультацию. Отчетность Service Desk Отчетность Службы, может быть использована для формализации отношений между клиентами и Фирмой, ожидаемый уровень поддержки (время реакции на запросы и исполнение запросов) может быть сопоставлен и приведен в соответствие финансированию и численности Службы. При помощи отчетности можно будет выявить закономерности в потоке поступающих запросов и выделить «узкие места» в ПС. Для оценки производительности процесса необходимо четко определить контрольные параметры и измеряемые оценки, часто называемые показателями эффективности. Отчет по этим показателям производится регулярно, например раз в неделю, чтобы получить картину изменений, по которой можно было бы определить тенденции. Примерами таких параметров являются: • общее количество инцидентов; • среднее время разрешения инцидентов; • среднее время разрешения инцидентов по приоритетам; • среднее число инцидентов, разрешенных в рамках соглашений (SLA); • процент инцидентов, разрешенных первой линией поддержки (без эскалации); • средняя стоимость поддержки на инцидент; • число решенных инцидентов на одно рабочее место или на одного сотрудника Service Desk; • инциденты, решенные без посещения пользователя (удаленно); • число (или процент) инцидентов с первоначально некорректной классификацией; Service Desk (main process) 21.09.2007 (версия 1.1) 16 • число (или процент) инцидентов, неправильно распределенных в группы поддержки. Одним из количественных показателей деятельности Service Desk является объем разрешений инцидентов при первом обращении. Если, например, этот показатель в отношении технической поддержки продуктов компании N в этом месяце составил 60%, это значит, что 60% заявок было выполнено специалистами первого уровня и только 40% ушло на второй. Service Level Agreement Соглашение об Уровне Услуг представляет собой соглашение между Фирмой и Клиентом, в котором подробно оговорены предоставляемые услуги. Данное соглашение описывает услуги в нетехнических терминах, на уровне понимания заказчика, и в течение срока действия соглашения оно является стандартом для оценки и корректировки предоставляемых ИТ-сервисов. Соглашение обычно имеет иерархическую структуру, например, услуги общего характера, такие как сетевые услуги и услуги службы Service Desk, определяются для всей организации и утверждаются руководством. Услуги более конкретного характера, предназначенные для бизнес-деятельности, согласуются на более низком уровне, например, с руководством бизнес-подразделения, владельцем бюджета или представителем заказчика. Для Service Desk важно иметь информацию по каждому SLA каждого клиента, так как это позволит отслеживать обязательства перед клиентом и графики обслуживания их Инцидентов. Например, наличие заключенного Соглашение об Уровне Услуг позволит адекватно идентифицировать требуемый к исполнению график работ, по устранению Инцидента, в соответствии с временными критериями, например: • Решение вопроса за 4 часа • Решение вопроса за 12 часов • Решение вопроса за 48 часов • Решение вопроса за 72 часа Service Desk (main process) 21.09.2007 (версия 1.1) 17 Управление Инцидентами (детальное описание) У этого процесса входами являются обращения пользователей (Инциденты и Запросы), а также автоматизированные алерты от различных мониторинговых систем, которые могут генерировать специальные оповещения, которые также будут поступать в Службу. На рисунке 5, показаны входы и выходы процесса, а также виды деятельности, которые охватывает этот процесс. Рис.5 Взаимосвязь процесса Управления Инцидентами с другими процессами Детальная схема самого процесса Управления Инцидентами, показана на рисунке 6, далее мы детально рассмотрим каждый этап этого процесса. Service Desk (main process) 21.09.2007 (версия 1.1) 18 Рис.6 Процесс Управления Инцидентами 1. Прием и регистрация инцидента (Acceptance and Recording) — принимается сообщение и создается запись об инциденте. 2. Классификация и начальная поддержка (Classification and Initial support) — присваиваются тип, статус, степень воздействия, срочность, приоритет инцидента, SLA и т. п. Пользователю может быть предложено возможное решение, даже если оно только временное. Service Desk (main process) 21.09.2007 (версия 1.1) 19 3. Если вызов касается Запроса на Обслуживание (Service Request), то инициируется соответствующая процедура. Привязка (или сопоставление — Matching) — проверяется, не является ли инцидент уже известным инцидентом или известной ошибкой, нет ли для него уже открытой проблемы, и нет ли для него известного решения или обходного пути. 4. Расследование и диагностика (Investigation and Diagnosis) — при отсутствии известного решения производится исследование инцидента с целью как можно быстрее восстановить нормальную работу. 5. Решение и восстановление (Resolution and Recovery) — если решение найдено, то работа может быть восстановлена. 6. Закрытие (Closure) — с пользователем связываются, чтобы он подтвердил согласие с предложенным решением, после чего инцидент может быть закрыт. 7. Мониторинг хода работ и отслеживание (Progress monitoring and Tracking) — весь цикл обработки инцидента контролируется, и если инцидент не может быть разрешен вовремя, производится эскалация. В большинстве случаев инциденты регистрируются Службой Service Desk, куда поступают сообщения о них. Регистрация всех инцидентов должна производиться немедленно после поступления сообщения по следующим причинам: • трудно произвести точную регистрацию информации об инциденте, если это не сделано сразу; • мониторинг хода работ по решению инцидента возможен, только если инцидент зарегистрирован; • зарегистрированные инциденты помогают при диагностике новых инцидентов; • Управление Проблемами может использовать зарегистрированные инциденты при работе над поиском корневых причин; • легче определить степень воздействия, если все сообщения (звонки) зарегистрированы; • без регистрации инцидентов невозможно контролировать исполнение договоренностей (SLA); • немедленная регистрация инцидентов предотвращает ситуации, когда или несколько человек работают над одним звонком, или никто ничего не делает для разрешения инцидента. Место обнаружения инцидента определяется по признаку, откуда пришло сообщение о нем. Инциденты могут быть обнаружены следующим образом: 1. Обнаружен пользователем: он докладывает об инциденте в Службу Service Desk. Service Desk (main process) 21.09.2007 (версия 1.1) 20 2. Обнаружен системой: при обнаружении события в приложении или технической инфраструктуре, регистрируется например, как при инцидент превышении в системе критического регистрации порога, инцидентов событие и, при необходимости, направляется в группу поддержки. 3. Обнаружен кем-либо в другом подразделении ИТ: этот специалист регистрирует инцидент в системе регистрации инцидентов или докладывает о нем в Службу. Необходимо избегать двойной регистрации одного инцидента. Поэтому при регистрации инцидента следует проверить, нет ли аналогичных открытых инцидентов: При регистрации инцидента производятся следующие действия: 1. Назначение номера инцидента: в большинстве случаев Система автоматически назначает новый (уникальный) номер инцидента. Часто этот номер сообщается пользователю, чтобы он мог ссылаться на него при дальнейших контактах. 2. Запись базовой диагностической информации: время, признаки (симптомы), пользователь, сотрудник, принявший вопрос в обработку, место произошедшего инцидента и информация о затронутой услуге и/или технических средствах. 3. Запись дополнительной информации об инциденте: добавляется информация, например, из процедуры опроса или из Конфигурационной Базы Данных — CMDB. 4. Объявление сигнала тревоги: если происходит инцидент, имеющий высокую степень воздействия, например, сбой важного сервера, производится предупреждение других пользователей и руководства. Классификация инцидентов направлена на определение его категории для облегчения мониторинга и составления отчетов. Желательно, чтобы опции классификации были как можно шире, но при этом требуется более высокий уровень ответственности персонала. Иногда пытаются объединить в одном перечне несколько аспектов классификации, таких, как тип, группа поддержки и источник. Это часто вносит путаницу. Лучше использовать несколько коротких перечней. Категория Прежде всего, инцидентам присваивается категория и подкатегория, например, исходя из предполагаемого источника инцидента или соответствующей группы поддержки: • Центральная процессинговая система — подсистема доступа, центральный сервер, приложение. • Сеть — маршрутизаторы, сегменты, концентратор, IP-адреса. • Рабочая станция — монитор, сетевая карта, дисковод, клавиатура. Service Desk (main process) 21.09.2007 (версия 1.1) 21 • Использование и функциональность — услуга (сервис), возможности системы, доступность, резервное копирование, документация. • Организация и процедуры — заказ, запрос, поддержка, оповещение (коммуникации). • Запрос на Обслуживание — запрос пользователя в Службу Service Desk на поддержку, предоставление информации, документации или оказание консультации. Это может быть выделено в от дельную процедуру или обработано таким же образом, как реальный инцидент. Приоритет После этого назначается приоритет, чтобы быть уверенными, что группа поддержки уделит инциденту необходимое внимание. Приоритет — это номер, определяющийся срочностью (насколько быстро это должно быть исправлено) и степенью воздействия (какой ущерб будет нанесен, если не исправить быстро). Приоритет = Срочность х Степень воздействия. Услуги (сервисы) Для определения услуг, подвергшихся воздействию инцидента, может быть использован перечень существующих договоренностей (соглашений) об Уровне Услуг — SLA. Этот перечень позволит также установить время эскалации для каждой из услуг, определенных в SLA. Группа поддержки Если Service Desk не может разрешить инцидент незамедлительно, то определяется группа поддержки, которая будет заниматься разрешением инцидента. Основой для распределения (маршрутизации) инцидентов часто является информация о категориях. При определении категорий может потребоваться рассмотрение структуры групп поддержки. Правильное распределение инцидентов имеет существенное значение для эффективности Процесса Управления Инцидентами. Поэтому одним из ключевых показателей эффективности (KPI) Процесса Управления Инцидентами может быть число неправильно распределенных обращений. Сроки решения С учетом приоритета и соглашения SLA пользователь информируется о максимальном расчетном времени разрешения инцидента. Идентификационный номер инцидента Абонент информируется о номере инцидента для его точной идентификации при последующих обращениях. Service Desk (main process) 21.09.2007 (версия 1.1) 22 Статус Статус инцидента указывает на его положение в процессе обработки инцидента. Примерами статусов могут быть: ③ новый; ③ принят; ③ запланирован; ③ назначен; ③ активный; ③ отложен; ③ разрешен; ③ закрыт. Привязка (сопоставление) После классификации проводится проверка, не возникал ли аналогичный инцидент ранее и может уже есть готовое решение. Если инцидент имеет те же признаки, что и открытая проблема или известная ошибка, то может быть установлена связь с ними. Расследование и диагностика Служба Service Desk или группа поддержки направляет инциденты, не имеющие готового решения или выходящие за пределы компетенции работающего с ним сотрудника, группе поддержки следующего уровня с большим опытом и знаниями. Эта группа исследует и разрешает инцидент или направляет его группе поддержки очередного уровня. В процессе разрешения инцидента различные специалисты могут обновлять регистрационную запись о нем, изменяя текущий статус, информацию о выполненных действиях, пересматривая классификацию и обновляя время и код работавшего сотрудника. Решение и восстановление После успешного завершения анализа и разрешения инцидента сотрудник записывает решение в систему. В некоторых случаях необходимо направить Запрос на Изменение (RFC) в Процесс Управления Изменениями. В наихудшем случае, если не найдено никакого решения, инцидент остается открыть. Закрытие После реализации решения, удовлетворяющего пользователя, группа поддержки направляет инцидент обратно в Service Desk. Эта служба связывается с сотрудником, сообщившим об инциденте, целью получения подтверждения об успешном решении вопроса. Если он это подтверждает, то инцидент может быть закрыт; в противном случае Service Desk (main process) 21.09.2007 (версия 1.1) 23 процесс возобновляется на соответствующем уровне. При закрытии инцидента необходимо обновить данные об окончательной категории, приоритете, сервисах (услугах), подвергшихся воздействию инцидента и Конфигурационной Единице (CI), вызвавшей сбой. Мониторинг хода решения и отслеживание В большинстве случаев ответственной за мониторинг хода решения является Service Desk, как «владелец» всех инцидентов. Эта служба должна также информировать пользователя о состоянии инцидента. Обратная связь с пользователем может быть уместной после изменения статуса, например, направление инцидента на следующую линию поддержки, изменение расчетного времени решения, эскалации и т. д. Во время мониторинга возможна функциональная эскалация к другим Возможные проблемы При внедрении Управления Инцидентами могут возникнуть следующие проблемы: 1. Клиенты и специалисты работают в обход процедур Управления Инцидентами — если пользователи будут устранять возникающие ошибки сами или напрямую связываться со специалистами, не следуя установленным процедурам, Фирма не получит информацию о реально предоставляемом Уровне Услуг, числе ошибок и многое другое. Отчеты руководству не будут адекватно отражать ситуацию. 2. Перегруженность инцидентами и откладывание «на потом» — при неожиданном росте количества инцидентов для правильной регистрации может не оказаться достаточно времени, т. к. до окончания ввода информации об инциденте от одного пользователя возникает необходимость обслуживать следующего. В этом случае ввод описания инцидентов может производиться недостаточно точно, и процедуры по распределению инцидентов не будут выполняться должным образом. В результате решения получаются не качественными, и рабочая нагрузка увеличивается еще больше. 3. Слишком большое число эскалации может оказать отрицательное воздействие на работу специалистов, которые из-за этого отрываются от своей запланированной работы. 4. Отсутствие Каталога Услуг и Соглашений об Уровне Сервисов (SLA) — если поддерживаемы услуги и продукты недостаточно точно определены, тогда специалистам, вовлеченным в Управление Инцидентами, бывает трудно обоснованно отказать клиентам в немедленной помощи либо назвать реальные сроки разрешения Инцидентов. Управление Проблемами (детальное описание) Service Desk (main process) 21.09.2007 (версия 1.1) 24 Целью Процесса Управления Проблемами является установление корневой причины возникновения проблемы и, как следствие, предотвращение инцидентов. Управление Проблемами включает в себя проактивные (упреждающие) и реактивные виды деятельности. Задачей реактивных составляющих Процесса Управления Проблемами является выяснение корневой причины прошлых инцидентов и подготовка предложения по ее ликвидации. Проактивное Управление Проблемами помогает предотвратить инциденты путем определения слабых мест в инфраструктуре и подготовки предложений по ее усовершенствованию. Управление Проблемами гарантирует, что: 1. существующие и регулярно возникающие ошибки идентифицированы, документированы и отслеживаются; 2. симптомы ошибок, постоянные или временные решения документируются; 3. подаются Запросы на Изменения с целью модификации инфраструктуры; 4. предотвращается возникновение новых инцидентов. Управление Проблемами позволяет быстро улучшить качество услуг путем значительного сокращения количества инцидентов и уменьшения рабочей нагрузки на ИТ-организацию. Некоторые из преимуществ данного процесса состоят в следующем: 1. Улучшение качества ИТ-услуг и Управления — результат документирования ошибок и/или их устранения. 2. Повышение производительности труда пользователей — за счет улучшения качества услуг. 3. Повышение производительности труда персонала — наличие документированных решений проблем позволяет даже менее опытным участникам Процесса Управления Инцидентами разрешать инциденты быстрее и эффективнее. 4. Улучшение репутации ИТ-услуг — в результате улучшения стабильности услуг заказчики с большим желанием сотрудничают с ИТ-организацией в новых сферах бизнеса. 5. Совершенствование знаний, эффективное обучение. Процесс Управления Проблемами позволяет хранить исторические данные, которые используются при определении тенденций, и помогают принять меры по предотвращению новых инцидентов. Исторические данные также можно использовать при проведении исследований и диагностирования, а также, при создании Запросов на Изменения. 6. Улучшение регистрации инцидентов — Управление Проблемами вводит стандарты на регистрацию и классификацию инцидентов с целью эффективного определения проблем и их симптомов. Это также помогает улучшить составление отчетов об инцидентах. 7. Более высокая доля инцидентов, разрешенных на первой линии поддержки, поскольку Процесс Управления Проблемами разрабатывает решения для ликвидации инцидентов и проблем, а обходные решения можно найти в базе знаний, то первая линия поддержки с большим успехом сама разрешает инциденты. Service Desk (main process) 21.09.2007 (версия 1.1) 25 На рис 7 показаны взаимосвязи между проблемой, известной ошибкой и Запросом на Изменение и даны определения этих терминов. Рис.7 Отношения между проблемами и известными ошибками Входами для Процесса Управления Проблемами являются: • детальные описания инцидентов; • обходные решения, найденные Процессом Управления Инцидентами; • детали конфигурации из Конфигурационной Базы Данных (CMDB); • подробная информация от производителя используемых в инфраструктуре продуктах, включая известные ошибки в этих продуктах и технические детали; • подробная информация об инфраструктуре и ее поведении, такая как записи об имеющихся мощностях, замеры производительности, отчеты о соблюдении Уровней Услуг и так далее. Основными видами деятельности в рамках Управления Проблемами являются: 1. контроль проблем: определение и исследование проблем; 2. контроль ошибок: отслеживание известных ошибок и подача Запросов на Изменения (RFC); 3. проактивное Управление Проблемами: предотвращение инцидентов; 4. предоставление информации: отчеты по серьезным проблемам и достигнутым результатам. Далее, мы подробнее остановимся только на первых двух видах деятельности. Выходами процесса являются: • известные ошибки; • Запросы на Изменения (RFC); • новые регистрационные данные о проблемах; • закрытые после устранения причины проблемы регистрационные записи; Service Desk (main process) 21.09.2007 (версия 1.1) 26 • информация для руководства. Контроль проблем Целью этого вида деятельности является выявление проблем и изучение их причин. Контроль проблем должен преобразовать проблему в известную ошибку путем диагностирования неизвестной причины ее возникновения. На рис. 8 показаны действия, выполняемые в рамках контроля проблемы. В принципе, любой инцидент, возникший по неизвестной причине, может быть связан с проблемой. На практике это имеет смысл делать только тогда, когда инцидент повторяется, возможно его повторение, или если это единичный, но серьезный инцидент. Анализ тенденций позволяет обнаружить области, которым требуется особое внимание. Необходимые для этого дополнительные ресурсы нужно обосновать с позиции издержек и выгод для организации. Например, определить области, которым требуется более действенная поддержка, и понять, насколько они важны для предоставляемых услуг. Рис. 8 Отношения между проблемами и известными ошибками Контроль ошибок Деятельность по Контролю ошибок заключается в ведении мониторинга и исправлении известных ошибок до момента их полного устранения (в тех случаях, когда это возможно и целесообразно). В рамках Контроля ошибок осуществляется деятельность по мониторингу всех известных ошибок с момента их идентификации и до устранения. К работе по Контролю ошибок привлекаются многие подразделения, как из операционной среды, так и из среды разработки. Service Desk (main process) 21.09.2007 (версия 1.1) 27 Рис.9 Контроль ошибок Документ подготовил Ющенко Игорь Согласовано 21-Сентября-2007 Капковский Юрий Service Desk (main process) 21.09.2007 (версия 1.1) 28 Приложение 1. Перечень Процессов ITSM 1. Управление инцидентами (Incident management). Цель процесса - скорейшее устранение инцидентов, под которыми понимаются любые события, требующие ответной реакции: сбои, запросы на консультации и т.п. C данным процессом рассматриваются вопросы создания и управления подразделения Service desk. 2. Управление проблемами (Problem management) . Цель - сделать так, чтобы инцидентов стало меньше. Это достигается за счет выявления и устранения причин инцидентов. 3. Управление конфигурациями (Configuration management). Цель - создать и поддерживать в актуальном состоянии логическую модель инфраструктуры. 4. Управление изменениями (Change management). Каждое изменение делается из благих намерений, но каждое изменение потенциально опасно для инфраструктуры. Цель процесса - допускать только разумные изменения, а также координировать проведение изменений. 5. Управление релизами (Release management). Если считать управление изменениями головой, то этот процесс - руки, которые производят изменения в инфраструктуре. Цель процесса - сохранить работоспособность производственной среды при проведении изменений. 6. Управление уровнем сервиса (Service level management). Зачастую поставщик и потребитель ИТ сервисов по-разному представляют себе, в чем эти сервисы состоят, какие операции и как быстро должны проводиться. Цель процесса - выявить требуемый состав и уровень сервиса, следить за его достижением, а при необходимости - инициировать действия по устранению некачественного сервиса. 7. Управление финансами (Financial management for IT services). Цель процесса обеспечить надежную финансовую базу для всех прочих процессов. 8. Управление мощностью (Capacity management). Недостаточная мощность инфраструктуры приводит к появлению жалоб на скорость работы, или, хуже того, к невозможности продолжать работу. С другой стороны, излишняя, неиспользуемая, мощность - это впустую потраченные деньги. Цель это ITIL процесса - найти разумный компромисс между затратами и потребностями. 9. Управление непрерывностью (IT service continuity management). Цель процесса обеспечить гарантированное восстановление инфраструктуры, необходимой для продолжения бизнес-операций, в случае чрезвычайной ситуации: пожара, наводнения, отключения электроэнергии. 10. Управление доступностью (Availability management). Доступность - очень часто используемый показатель уровня сервиса. Однако не только обеспечение заданного уровня доступности, но даже определение и измерение доступности настолько сложны, что для всех связанных с доступностью задач организуется отдельный процесс. Service Desk (main process) 21.09.2007 (версия 1.1) 29 Приложение 2. Схема организации идеальной службы Service Desk Service Desk (main process) 21.09.2007 (версия 1.1) 30 Приложение 3. Основные процессы (workflow) Service Desk Service Desk (main process) 21.09.2007 (версия 1.1) 31 Приложение 4. Основные преимущества Service Desk Service Desk (main process) 21.09.2007 (версия 1.1) 32 Приложение 5. Примерный план внедрения Help Desk Выполняемые работы Результаты Этап 1 Формализация требований. Согласованное и утвержденное Согласование Техническое задание. Технического Задания. План работ. Планирование работ. Этап 2 Разработка и обоснование проектных решений для реализации требований к подсистемам "Взаимодействие с пользователями и управление работами", "Управление конфигурациями" и "Управление изменениями" в функциональной, информационной, аппаратной и программной части. Разработка структуры Разработка каталога конфигурационной ключевых базы информационных данных. услуг. Технический проект, включающий: • описание архитектуры и структуры подсистемы; • описание программного обеспечения и проектных решений. Разработка сервисной модели ключевых информационных услуг. Регламентация процедур. Описание функциональных ролей. Разработка критериев качества (метрик). Проектирование пользовательского интерфейса. Согласование и утверждение проектной документации. Этап 3 Поставка, инсталляция, настройка и оптимизация программного обеспечения. Получение информации и первоначальное информационное наполнение конфигурационной базы данных. Загрузка справочных данных. Настройка пользовательского интерфейса для различных АРМ. Настроенный аппаратно программный комплекс Системы Help Desk. Рабочая документация, включающая: Интеграция с почтовой программой. • инструкцию Разработка эксплуатационных документов, обеспечивающих выполнение функций с использованием специального программного обеспечения. • инструкцию Тестирование системы. администратора; диспетчера; • инструкцию исполнителя (инженера); • настройки сервера приложений; • настройки сервера базы данных; • настройки типовых АРМ; Заполненные справочники и конфигурационная база данных. Этап 4 Назначение функциональных ролей сотрудникам и определение границ ответственности персонала. Система Help Desk готовая к эксплуатации. Обучение персонала. Обученные пользователи. Service Desk (main process) 21.09.2007 (версия 1.1) 33
