Контрольная работа - Service Desc - файл n1.doc

Контрольная работа - Service Desc
скачать (1835.5 kb.)
Доступные файлы (1):
n1.doc1836kb.06.11.2012 09:42скачать

n1.doc

Оглавление.


Оглавление. 2

1. Процессный подход. 4

2. Схема и структура работы Service Desk 6

3. Основная терминология. 9

4. Основные процессы службы Service Desk 11

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

4.2. Управление Проблемами. 13

5. Роли и ответственность сотрудников Service Desk. 15

5. Управление Инцидентами (детальное описание). 17

Заключение. 24

Список литературы. 26


Введение.

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

  1. "Центр приема сообщений" (Call Centre)

  2. "Диспетчерская помощи клиентам" (Help Desk)

  3. "Сервис-диспетчерская" (Service Desk)

В 1999 году в Европе было около 12 750 разнообразных "Центров приема сообщений", при тенденции увеличения их числа до 28 300 в 2006 году.

В США в 1999 году их было 69 500 и к 2003 году ожидается порядка 78 000.

В самом общем виде Service Desk обеспечивает единую точку контакта для пользователей, клиентов и возможных "внешних" организаций. Service Desk отстаивает интересы клиента перед остальным персоналом. Далее, Service Desk несет ответственность за устранение возникшего инцидента. Даже если реально работы выполняются специалистами других подразделений (в том числе - и "внешними" партнерами), полный учет времени устранения инцидента, контроль за процессом устранения, информирование пользователя о состоянии проблемы, информирование руководства о задержках в устранении их причинах, все это - обязанности службы Service Desk. Как и предыдущая, эта функция в большей степени ориентирована на клиента и качество предоставляемых ему сервисов. При этом не надо забывать, что службе должны быть предоставлены соответствующие права.

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

Любой вид бизнеса, должен приносить удовлетворение потребителям. Старайтесь не оставлять жалобы клиентов без внимания. Делайте правильные выводы, оперативно устраняйте причины недовольства Ваших клиентов, и в результате Вы сумеете сохранить доверие своих покупателей.

1. Процессный подход.


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

  1. Что должно быть сделано.

  2. Какой ожидается результат.

  3. Каким образом можно определить (измерить), что в результате работы процесса достигается ожидаемый результат.

  4. Как результаты выполнения одного процесса влияют на результаты других процессов.

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



Рис.1 Модель совершенствования процессов

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

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

Стандарты для выходных данных каждого процесса должны быть определены таким образом, чтобы вся цепочка процессов обеспечивала достижение корпоративных стратегических целей. Если результат процесса отвечает заданному стандарту, такой процесс будет считаться эффективным (effective). Если работы в рамках данного процесса к тому же выполняются с наименьшими усилиями и затратами, этот процесс будет рациональным (efficient). Цель Управления Процессами — планировать и контролировать процессы таким образом, чтобы они были одновременно эффективными и рациональными. Для оптимизации качества процессов каждый из них можно рассматривать отдельно. Владелец процесса несет ответственность за результаты работы процесса. Менеджер процесса отвечает за его структуру и выполнение и подотчетен владельцу процесса. Координаторы процесса отвечают за выполнение заданных видов работ и отчитываются о их результатах выполнения менеджеру процесса.

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

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

2. Схема и структура работы Service Desk


В общем случае работа Service Desk может быть представлена из пяти основных этапов:

  1. Пользователь обращается в Службу с заявкой о Проблеме (Инциденте).

  2. Оператор выполняет анализ заявки, и присваивает ей Категорию, при возможности помогает пользователю решить проблему с помощью Базы Знаний.

  3. Координатор назначает Инженера для решения заявки и фиксирует ее закрытие.

  4. Инженер решает проблему либо возвращает ее координатору.

  5. Выполняются работы по извещению пользователя.

Структура Service Desk напоминает луковицу (рис. 2). Ее сердцевина —программно-аппаратный комплекс, называемый центром обработки вызовов, который обеспечивает грамотное распределение заявок. Например, для этих целей может применяться решение IP Contact Center компании Cisco Systems. Вокруг него строится Help Desk, который отличается от Service Desk тем, что участвует только в одном процессе — в управлении инцидентами.

Соответственно, задачи Help Desk — зарегистрировать инцидент и как можно быстрее восстановить нормальную работу сервиса самостоятельно либо привлечь группу специалистов более высокого уровня для полного устранения причины инцидента. Но мы

должны не только «тушить пожары», но и предупреждать их. Мы должны оказывать бизнесу дополнительные услуги и именно этим и занимается Service Desk, как структурное подразделение.



Рис 2. Структура Service Desk

Техническая поддержка, как процесс, может иметь несколько уровней, но обычно их три.

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

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

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

Переход Инцидента на очередной уровень технической поддержки (Эскалация) означает увеличение времени и стоимости его разрешения. Разумеется, следует стремиться к тому, чтобы больше Инцидентов решать уже на первом уровне, где специалисты хотя и квалифицированные, но значительно более дешевые, чем, на третьем уровне. Схема маршрутизации Инцидента, показана на рисунке 3, на рисунке показана Функциональная эскалация (горизонтальная).
Р
ис 3. Уровень поддержки Service Deck.

3. Основная терминология.


Основными терминами и их трактовки

Запрос на обработку Инцидентов – запрос от пользователя в Service Desk, к таким запросам можно отнести все запросы, как о Проблемах, так и об Инцидентах.

Запрос на Обслуживание (Service Request) – это запрос от пользователя на предоставление информации, консультации или документации, не являющийся Запросом о Проблеме.

Примеры Запросов на обслуживание:

Для того чтобы можно было отличить Инциденты от «Инцидентов-Запросов на Обслуживание», рекомендуется присваивать Запросам на Обслуживание специальную категорию.

Запрос на Изменение (RFC) — это устное обращение или экранная (бумажная форма), используемая для записи детальной информации о предлагаемом запросе на изменение каких-либо характеристик ПС либо в ИТ инфраструктуре. Запрос RFC считается завершенным после проведения изменения в инфраструктуре, например, замены зарегистрированных компонентов, инсталляции ПК и т. д.

При одновременной обработке нескольких Инцидентов необходимо расставлять приоритеты. Обоснованием для назначения приоритета служит уровень важности ошибки для бизнеса и для клиента. На основе диалога с пользователем и в соответствии с положениями SLA, Служба назначает приоритеты, определяющие порядок обработки Инцидентов. При эскалации инцидентов на вторую, третью или более линии поддержки, тот же приоритет должен быть соблюден, но иногда он может быть скорректирован по согласованию со Службой. Каждый пользователь будет считать, что его Инцидент имеет наивысший приоритет, но мнения пользователей часто бывают субъективными. Для объективной оценки приоритета в диалоге с пользователем употребляются следующие критерии:

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

  2. Срочность инцидента: приемлемая задержка разрешения Инцидента для клиента или бизнес - процесса.

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

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

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

4. Основные процессы службы Service Desk


основными процессами для Service Desk(a) являются: Процесс Управления инцидентами (Incident Management) и Процесс Управления проблемами (Problem Management).

Основная цель процесса Управления Инцидентами — скорейшее восстановление нормального функционирования сервиса в соответствии с Соглашением об уровне услуг и минимизация воздействия отказа на жизнедеятельность бизнеса.

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

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


Этот процесс носит реактивный характер (фиксация и разрешения Инцидентов). его часто связывают со службой Help Desk. Он направлен на быстрое восстановление обслуживания путем устранения неполадок, возникающих в инфраструктуре либо в работе ПС. Задача процесса Управления Инцидентами - свести к минимуму случаи прерывания обслуживания или прерывания в работе сервиса. Он играет роль овседневного интерфейса общения между клиентами и Фирмой, что делает его необходимым для успешного управления удовлетворенностью клиентов. Процесс можно охарактеризовать как сочетание обработки обращений и эффективной поддержки первого, второго и третьего уровней. Разграничение между Инцидентами и Проблемами иногда может запутывать, но его главное отличие заключается в установлении различия между быстрым восстановлением услуги и установлением причины инцидента и ее устранением. Все Инциденты регистрируются, причем качество регистрационной информации определяет эффективность ряда других процессов. Типовой перечень задач, относящийся к Управлению Инцидентами, и методы контроля качества его работы указаны в Таблице №1.

Реализация

Контроль качества

Прием обращений

Регистрация инцидента

Эскалация инцидента

Классификация инцидентов

Отслеживание истории инцидентов

Разработка структуры Службы Помощи

Создание системы контроля и различной

регламентирующей документации Службы Помощи

Определение приоритетов

Изоляция неполадок

Удаление неполадок

Составление административных отчетов

Уведомление клиентов

Закрытие дела

Непрерывное совершенствование процесса

Таблица №1. Деятельность по управлению инцедентами.

4.2. Управление Проблемами.


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

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

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



Реализация

Контроль качества

Анализ тенденций в возникновении проблем

Регистрация проблем

Отслеживание истории проблем

Решение проблем

Создание системы контроля проблем/известных ошибок

Создание превентивных процедур технического обслуживания

Разработка методов анализа известных ошибок

Выявление источника

Анализ известных ошибок

Контроль известных ошибок

Создание интерфейсов поддержки поставщиков

Установка и поддержание контактов поддержки

Закрытие дел по проблемам и известным ошибкам

Составление административных отчетов

Непрерывное совершенствование процесса

Таблица №2. Деятельность по управлению проблемами.

5. Роли и ответственность сотрудников Service Desk.


Для распределения обязанностей (ролей) сотрудников службы поддержки, необходимо учитывать размер организации и основные соглашения уровня обслуживания (SLA), между Service Desk и бизнесом. Важно помнить, что речь идет об описании ролей, а не позиций. Для решения задач Службы необходимо выделить следующие роли:

  1. Менеджер службы поддержки.

  2. Аналитик службы поддержки.

1. Менеджер:

У менеджера Service Desk, большинство задач связанны с координацией работы всей службы и его непрерывного развития. Основные задачи для него указаны далее:

2. Аналитик (инженер, диспетчер):

Роль аналитика Service Desk ответственна за выполнение ежедневных задач и процессов Службы. Эта роль, прежде всего, связана с выполнением процесса Управления Инцидентами. В первые моменты цикла жизни Инцидента, аналитики Service Desk ответственны за корректную регистрацию и классификацию Инцидента, оказание начальной поддержки. На стадии начальной поддержки, они ответственны за разрешение максимального количества Инцидентов, насколько это возможно в пределах определенных временных рамок. Эти действия напрямую связанны с удовлетворением клиента и определяют дальнейшую судьбу Инцидента в цепи поддержки. Аналитики Службы ответственны за назначение Инцидентов, которые не были решены сразу. Однако их ответственность на этом не заканчивается, они продолжают сохранять ответственность за Инцидент, чтобы гарантировать, что они продолжают обрабатываться в соответствии с целями обслуживания, он также информирует клиента о прогрессе работ в течение всей жизни Инцидента. Как только Инцидент разрешен, аналитик должен убедиться, что клиент удовлетворен решением, и только потом закрыть инцидент. Эта роль также включает начальную обработку всех типов Запросов, поступающих в Service Desk и обслуживания таких внутренних элементов инфраструктуры Service Desk(a), как, например, пополнение базы Knowledge Base или пополнение списка Часто Задаваемых Вопросов. Эта роль ответственна за следующие действия:

5. Управление Инцидентами (детальное описание).


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

Рис. 4. Взаимосвязь процесса Управления Инцидентами с другими процессами.

Детальная схема самого процесса Управления Инцидентами, показана на рисунке 5.

Р

ис. 5. Процесс Управления Инцидентами.

1. Прием и регистрация инцидента (Acceptance and Recording) — принимается сообщение и создается запись об инциденте.

2. Классификация и начальная поддержка (Classification and Initial support) - присваиваются тип, статус, степень воздействия, срочность, приоритет инцидента, SLA и т. п. Пользователю может быть предложено возможное решение, даже если оно только временное.

3. Если вызов касается Запроса на Обслуживание (Service Request), то инициируется соответствующая процедура. Привязка (или сопоставление — Matching) — проверяется, не является ли инцидент уже известным инцидентом или известной ошибкой, нет ли для него уже открытой проблемы, и нет ли для него известного решения или обходного пути.

4. Расследование и диагностика (Investigation and Diagnosis) — при отсутствии известного решения производится исследование инцидента с целью как можно быстрее восстановить нормальную работу.

5. Решение и восстановление (Resolution and Recovery) — если решение найдено, то работа может быть восстановлена.

6. Закрытие (Closure) — с пользователем связываются, чтобы он подтвердил согласие с предложенным решением, после чего инцидент может быть закрыт.

7. Мониторинг хода работ и отслеживание (Progress monitoring and Tracking) — весь цикл обработки инцидента контролируется, и если инцидент не может быть разрешен вовремя, производится эскалация. В большинстве случаев инциденты регистрируются Службой Service Desk, куда поступают сообщения о них. Регистрация всех инцидентов должна производиться немедленно после поступления сообщения по следующим причинам:

Место обнаружения инцидента определяется по признаку, откуда пришло сообщение о нем.

Инциденты могут быть обнаружены следующим образом:

  1. Обнаружен пользователем: он докладывает об инциденте в Службу Service Desk.

  2. Обнаружен системой: при обнаружении события в приложении или технической инфраструктуре, например, при превышении критического порога, событие регистрируется как инцидент в системе регистрации инцидентов и, при необходимости, направляется в группу поддержки.

  3. Обнаружен кем-либо в другом подразделении ИТ: этот специалист регистрирует инцидент в системе регистрации инцидентов или докладывает о нем в Службу.

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

При регистрации инцидента производятся следующие действия:

  1. Назначение номера инцидента: в большинстве случаев Система автоматически назначает новый (уникальный) номер инцидента. Часто этот номер сообщается пользователю, чтобы он мог ссылаться на него при дальнейших контактах.

  2. Запись базовой диагностической информации: время, признаки (симптомы), пользователь, сотрудник, принявший вопрос в обработку, место произошедшего инцидента и информация о затронутой услуге и/или технических средствах.

  3. Запись дополнительной информации об инциденте: добавляется информация, например, из процедуры опроса или из Конфигурационной Базы Данных — CMDB.

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

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

Категория:

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

Это может быть выделено в от дельную процедуру или обработано таким же образом, как реальный инцидент.

Приоритет:

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

Услуги (сервисы):

Для определения услуг, подвергшихся воздействию инцидента, может быть использован перечень существующих договоренностей (соглашений) об Уровне Услуг — SLA. Этот перечень позволит также установить время эскалации для каждой из услуг, определенных в SLA.

Группа поддержки:

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

Сроки решения:

С учетом приоритета и соглашения SLA пользователь информируется о максимальном расчетном времени разрешения инцидента.

Идентификационный номер инцидента:

Абонент информируется о номере инцидента для его точной идентификации при последующих обращениях.

Статус

Статус инцидента указывает на его положение в процессе обработки инцидента.

Примерами статусов могут быть:

Привязка (сопоставление):

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

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

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

Решение и восстановление:

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

Закрытие

После реализации решения, удовлетворяющего пользователя, группа поддержки направляет инцидент обратно в Service Desk. Эта служба связывается с сотрудником, сообщившим об инциденте, целью получения подтверждения об успешном решении вопроса. Если он это подтверждает, то инцидент может быть закрыт; в противном случае процесс возобновляется на соответствующем уровне. При закрытии инцидента необходимо обновить данные об окончательной категории, приоритете, сервисах (услугах), подвергшихся воздействию инцидента и Конфигурационной Единице (CI), вызвавшей сбой.

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

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

Заключение.


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

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

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

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

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

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

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

Некоторые из преимуществ данного процесса состоят в следующем:

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

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

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

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

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

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

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

Список литературы.


  1. ИТ сервис-менеджмент. Введение. itSMF. – М.: IT Expert, 2003. – 228 с.

  2. Аксенов. Е, Аутсорсинг И. А. 10 заповедей и 21 инструмент. — СПб.: Питер, 2009. — 464 с.

  3. http://www.nestor.minsk.by

  4. http://www.cio-world.ru



Учебный материал
© bib.convdocs.org
При копировании укажите ссылку.
обратиться к администрации