Введение в ИТ СЕРВИС-МЕНЕДЖМЕНТ















Содержание


Глава 1 Введение 8

Глава 2 ИТ Сервис-менеджмент: общая картина 11

2.1 Услуги и качество 11

2.1.1. Гарантия качества 13

2.1.2. Организационная зрелость 15

2.2. Организация и ее политика (правила работы) 18

2.2.1. Корпоративная цель организации, ее миссия и правила 18

2.2.2. Горизонт планирования 22

2.2.3. Корпоративная культура 23

2.2.4. Управление Персоналом 23

2.2.5. Управление Взаимоотношениями с Заказчиками ИТ-услуг 25

2.3. Процессное управление 27

2.3.1. Процессы 28

2.3.2. Процессы и организационные подразделения 31

2.3.3. ИТ Сервис-менеджмент 32

Глава 3 Введение в ITIL 33

3.1 Общая картина 33

3.2. Организации 35

3.2.1. OGC (CCTA) 35

3.2.2. Форум itSMF 36

3.2.3. Организации EXIN и ISEB 36

3.3. Книги библиотеки ITIL 38

3.3.1. Предоставление услуг 40

3.3.2. Поддержка услуг 43

3.3.3. Другие рассматриваемые процессы 44

Глава 4 Управление Инцидентами 48

4.1. Введение 48

4.1.1. Терминология 49

4.2. Цель 52

4.2.1. Преимущества использования процесса 53

4.3. Процесс 53

4.3.1. Входы процесса 54

4.3.2. Управление конфигурациями 54

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

4.3.4. Управление Изменениями 55

4.3.5. Управление Уровнем Услуг 55

4.3.6. Управление Доступностью 55

4.3.7. Управление мощностями 56

4.4. Виды деятельности 57

4.4.1. Прием и регистрация 57

4.4.2. Классификация 59

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

4.4.4. Расследование и диагностика 60

4.4.5. Решение и восстановление 60

4.4.6. Закрытие 61

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

4.5. Контроль процесса 61

4.5.2. Показатели эффективности 62

4.5.3. Функции и роли 63

4.6. Затраты и проблемы 63

4.6.1. Затраты 63

4.6.2. Проблемы 64

Глава 5 Управление Проблемами 65

5.1. Введение 65

5.1.1. Определение – "проблема" и "известная ошибка" 65

5.1.2. Взаимоотношения с Процессом Управления Инцидентами 66

5.2. Цель процесса 66

5.3. Процесс 67

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

5.3.2. Управление Изменениями 69

5.3.3 Управление Конфигурациями 69

5.3.4. Управление Доступностью 69

5.3.5. Управление Мощностями 70

5.3.6. Управление Уровнем Услуг 70

5.4. Виды деятельности 70

5.4.1. Контроль проблем 70

5.4.2. Контроль ошибок 73

5.4.3. Проактивное Управление Проблемами 75

5.5 Управление Процессом 75

5.5.2. Критические факторы успеха 76

5.5.3. Функции и роли 77

5.6. Затраты и проблемы 78

5.6.1. Затраты 78

5.6.2. Проблемы 78

Глава 6. Управление Конфигурациями 78

6.1. Введение 79

6.1.1. Основные понятия 80

6.2. Цель процесса 82

6.2.1. Преимущества использования процесса 82

6.3. Процесс 84

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

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

6.3.3. Управление Изменениями 85

6.3.4. Управление Релизами 85

6.3.5. Управление Уровнем Услуг 85

6.3.6. Управление Финансами 86

6.3.7. Управление Доступностью 86

6.3.8. Управление Непрерывностью ИТ-услуг 86

6.3.9. Управление Мощностями 86

6.3.10. Виды деятельности 86

6.4. Виды деятельности 87

6.4.1. Планирование 87

6.4.2. Идентификация 87

6.4.3. Мониторинг статуса 96

6.4.4. Контроль 97

6.4.5. Верификация и аудит 98

6.5. Контроль процесса 99

6.5.1. Отчеты и Ключевые показатели эффективности 99

6.5.2. Критические факторы успеха 100

6.5.3. Функции и роли 100

6.6. Затраты и проблемы 101

6.6.1. Затраты 101

6.6.2. Проблемы 101

Глава 7 Управление Изменениями 102

7.1. Введение 102

7.1.1. Основные термины 104

7.2. Цель процесса 105

7.2.1. Преимущества использования процесса 106

7.3. Процесс 106

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

7.3.2. Управление Конфигурациями 107

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

7.3.4. Управление Релизами 108

7.3.5. Управление Уровнем Сервиса 108

7.3.6. Управление Доступностью 108

7.3.7. Управление Мощностями 108

7.3.8. Управление Непрерывностью ИТ-услуг 108

7.3.9. Виды деятельности в рамках Процесса Управления Изменениями 109

7.4. Виды деятельности 110

7.4.1. Регистрация 110

7.4.2. Прием в обработку 112

7.4.3. Классификация 113

7.4.4. Планирование 114

7.4.5. Координация 116

7.4.6. Оценка 118

7.4.7. Проведение срочных изменений 118

7.5 Контроль процесса 119

7.5.1 Отчеты для руководства 119

7.6. Затраты и проблемы 120

7.6.1. Затраты 120

7.6.2. Проблемы 120

7.6.3. Предложения 121

Глава 8 Управление Релизами 122

8.1. Введение 122

8.1.1. Основные понятия 123

8.2. Цель процесса 127

8.2.1. Преимущества использования процесса 128

8.3. Процесс 128

8.3.1. Управление Конфигурациями 129

8.3.2. Управление Изменениями 129

8.3.3. Управление Уровнем Услуг 130

8.3.4. Виды деятельности 130

8.4. Виды деятельности 130

8.4.1. Выработка политики в отношении релизов и планирование 130

8.4.2. Проектирование, компоновка и конфигурирование 131

8.4.3. Тестирование и приемка релиза 133

8.4.4. Планирование внедрения 134

8.4.5. Оповещение, подготовка и обучение 134

8.4.6. Распространение релизов и инсталляция 135

8.5. Затраты и проблемы 135

8.5.1. Затраты 135

8.5.2. Проблемы 135

Глава 9 Служба Service Desk 136

9.1. Введение 136

9.2. Цель 138

9.3. Структура 138

9.3.1. Доступность 138

9.3.2. Поддержка бизнеса 138

9.3.3. Варианты организации Службы Service Desk 139

9.3.4. Персонал Службы Service Desk 142

9.3.5. Технологии для работы Службы Service Desk 142

9.4. Виды деятельности 143

9.4.1. Ответы на обращения 143

9.4.2. Предоставление информации 144

9.4.3. Взаимодействие с поставщиками 144

9.4.4. Операционные задачи 144

9.4.5. Мониторинг инфраструктуры 145

9.5. Эффективность 145

9.5.1. Отчеты руководству 145

9.5.2. Критические факторы успеха 146

Глава 10 Управление Уровнем Сервиса (Услуг) 146

10.1. Введение 146

10.1.1. Основные понятия 146

10.2. Цель процесса 149

10.3. Процесс 149

10.4. Виды деятельности 155

10.4.1. Идентификация 155

10.4.2. Определение 155

10.4.3. Договор 158

10.4.4. Мониторинг 159

10.4.5. Создание отчетов 159

10.4.6. Анализ (ревью) 160

10.5. Контроль процесса 160

10.5.1. Критические факторы успеха и ключевые показатели эффективности 161

10.5.2. Отчеты руководству 161

10.5.3. Функции и роли 162

10.6. Проблемы и затраты 162

10.6.1. Проблемы 162

10.6.2. Затраты 163

Глава 11 Управление Финансами ИТ 163

11.1. Введение 163

11.1.1. Основные понятия 164

11.2. Цели процесса 167

11.3. Процесс 169

11.4. Виды деятельности 171

11.4.1. Составление бюджета 171

11.4.2. Бухгалтерский учет 173

11.4.3. Выставление счетов 174

11.4.4. Отчетность 176

11.5. Контроль процесса 177

11.5.1. Отчеты для руководства 177

11.5.2. Критические факторы успеха и ключевые показатели эффективности 177

11.5.3. Функции и роли 178

11.6. Проблемы и затраты 178

11.6.1. Проблемы 178

11.6.2. Затраты 179

Глава 12 Управление Мощностями 179

12.1. Введение 179

12.1.1. Основные понятия 179

12.2. Цели процесса 180

12.3. Процесс 181

12.4. Виды деятельности 185

12.4.1. Управление Возможностями Бизнеса (Business Capacity Management) 185

12.4.2 Управление Возможностями Сервисов и Управление Мощностями Ресурсов 186

12.5. Контроль процесса 189

12.5.1. Отчеты для руководства 189

12.5.2. Критические факторы успеха и Ключевые Показатели Эффективности (КPI) 189

12.5.3. Функции и роли 190

12.6. Проблемы и затраты 190

12.6.1. Проблемы 190

12.6.2. Затраты 191

Глава 13 Управление Непрерывностью ИТ-сервисов 192

13.1. Введение 192

13.2. Цель процесса 193

13.3. Процесс 193

13.4. Виды деятельности 194

13.4.1. Определение охвата (области действия) Процесса Управления Непрерывностью ИТ-сервисов 196

13.4.2. Анализ воздействия на бизнес 196

13.4.4. Стратегия обеспечения непрерывности ИТ-сервисов 199

13.4.5. Организация процесса и планирование внедрения 203

13.4.6. Применение превентивных мер и способов восстановления 203

13.4.7. Разработка планов и процедур восстановления 204

13.4.8. Начальное тестирование 205

13.4.9. Обучение и осведомление 206

13.4.10. Анализ и аудит 206

13.4.11. Тестирование 206

13.4.12. Управление Изменениями 206

13.4.13. Обеспечение гарантий 207

13.5. Управление Процессом 207

13.5.1. Отчеты для руководства 207

13.5.2. Критические факторы успеха и ключевые показатели качества 207

13.5.3. Функции и роли 207

13.6. Проблемы и затраты 208

13.6.1. Затраты 208

13.6.2. Проблемы 209

Глава 14 Управление Доступностью 210

14.1. Введение 210

14.1.1. Основные понятия 210

14.2. Цели процесса 212

14.2.1. Преимущества использования процесса 212

14.3. Процесс 214

14.4. Виды деятельности 215

14.4.1. Определение требований к доступности сервиса 215

14.4.2. Проектирование систем для достижения требуемого Уровня Доступности 216

14.4.3. Проектирование систем для достижения требуемого Уровня Обслуживания 216

14.4.4. Ключевые вопросы безопасности 217

14.4.5. Управление Обслуживанием 217

14.4.6. Проведение измерений и составление отчетов 217

14.4.7. Разработка Плана Обеспечения Доступности 219

14.4.8. Инструментальные средства 220

14.4.9. Методы и методики 220

14.5. Контроль процесса 224

14.5.1. Составление отчетов 224

14.5.2. Критические факторы успеха и ключевые показатели эффективности 224

14.5.3. Функции и роли 224

14.6. Проблемы и затраты 225

14.6.1. Проблемы 225

14.6.2. Затраты 226

Глава 15 Управление Информационной Безопасностью 226

15.1. Введение 226

15.1.1. Основные понятия 227

15.2. Цели процесса 228

15.2.1. Преимущества использования процесса 229

15.3. Процесс 229

15.3.1. Взаимоотношения с другими процессами 231

15.3.2. Раздел по Безопасности Соглашения об Уровне Сервиса 235

15.3.3. Раздел по Безопасности Операционного Соглашения об Уровне Услуг (OLA) 237

15.4. Виды деятельности 238

15.4.1. Контроль – политика и организация информационной безопасности 238

15.4.2. Планирование 239

15.4.3. Реализация 240

15.4.4. Оценка 241

15.4.5. Поддержка 241

15.4.6. Составление отчетов 242

15.5. Контроль процесса 243

15.5.1. Критические факторы успеха и ключевые показатели эффективности 243

15.5.2. Функции и роли 243

15.6. Проблемы и затраты 243

15.6.1. Проблемы 243

15.6.2. Затраты 244

Приложение А. Фирма "Quick Couriers" ("Быстрые курьеры") 245

А.1. Управление Конфигурациями 246

А.2. Управление Инцидентами и Служба Service Desk 247

A.3. Управление Проблемами 248

А.4. Управление Изменениями 248

А.5. Управление Релизами 249

А.6. Управление Доступностью 250

А.7. Управление Мощностями 250

А.8. Управление Непрерывностью ИТ-сервиса 251

А.9. Управление Финансами 252

А.10. Управление Уровнем Услуг 253

Приложение В 253

В1. Акронимы 253

В2. Дополнительный материал 255

В.3. Веб-сайты 256

























Глава 1 Введение


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

В 80-х годах качество ИТ-услуг, предоставляемых британскому правительству было таким, что существовавшее в то время Центральное агентство по вычислительной технике и телекоммуникациям (Central Computer and Telecommunications Agency – CCTA, в на стоящее время именуемое Office of Government Commerce – OGC) получило указание разработать принципы эффективного и рентабельного использования ИТ-ресурсов в министерствах и других государственных учреждениях Великобритании. Целью данной компании была разработка единого подхода, не зависящего от поставщика услуг. Результатом усилий явилась Библиотека передового опыта организации ИТ (IT Infrastructure Library[1]), которая выросла из собрания лучших методов, существовавших в индустрии ИТ-услуг.

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

На базе библиотеки ITIL некоторые коммерческие компании разработали свои структурированные подходы к Управлению ИТ-услугами. Среди них HP ITSM Reference Model компании Hewlett-Packard, IT Process Model компании IBM, MOF компании Microsoft и многие другие. Это стало одной из причин, по которым библиотека ITIL фактически стала стандартом в описании фундаментальных процессов ИТ Сервис-менеджмента (IT Service Management – ITSM)[2]. Такое принятие библиотеки ITIL напрямую отражает ее философию и делает ее долгожданной областью знаний, поскольку она послужила толчком к установлению единообразия в индустрии ИТ, столь необходимого в современной распределенной среде.

Более широкое распространение библиотеки ITIL было затруднено отсутствием начальной, но достаточно эффективной книги, являющейся основой для самообучения. Данная книга предназначена для тех, кто участвует в Управлении ИТ-сервисами или интересуется данной темой. Для широкой аудитории в мире дополнительным каналом информации является некоммерческая организация "Форум по ИТ Сервис-менеджменту" (itSMF). Цели преследуемые itSMF и этой книгой, одинаковы.

Свою миссию itSMF видит в следующем:

"Цель itSMF как независимой и некоммерческой организации – продвижение современных знаний и опыта в области ИТ Сервис-менеджмента".

itSMF движется к этой цели путем проведения конференций, семинаров, издания журнала публикации журнала, публикации книг. Форум itSMF также заинтересован в привлечении новых членов.

Данная книга, публикуемая itSMF, ставит перед собой следующую цель:

"Сделать знания и опыт по ИТ Сервис-менеджменту доступными для более широкой аудитории".

Итак, задачами книги являются:

1. Содействие миссии itSMF путем публикации доступного руководства по ИТ Сервис-менеджменту, которое также можно использовать при подготовке к сдаче экзаменов по ITIL.

2.П Принятие ITIL в качестве фактического стандарта и структурированного подхода[3] для изложения материала книги.

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

4. Гарантия независимости содержания от влияния конкретных поставщиков.

Принимая во внимание быстрое развитие данной области, книги ITIL не всегда могут дать описание самых последних разработок. ITIL, в первую очередь, - собрание передового опыта, накопленного в индустрии, а теория и практика не всегда шагают рядом. При написании книги мы хотели собрать воедино разработки в данной области, не отходя при этом существенно от публикаций ITIL. Поэтому данная книга может быть использована как самоучитель при подготовке к экзамену по ITIL и как введение в более широкую область ИТ Сервис-менеджмента. В этом издании не рассматривается планирование и внедрение ITIL-процессов. Хотя в главе "ИТ Сервис-менеджмент – общая картина" эти вопросы затрагиваются через рассмотрение более широких понятий, таких как качество, процессы и правила работы компании[4].

Первое издание книги базируется на публикациях itSMF, изданных в Нидерландах, как введение в ИТ Сервис-менеджмент. Эта книга, в свою очередь, основывалась на главах "Краткие сведения для руководства" и некоторых описаниях из официальных изданий библиотеки ITIL с разрешения OGC. Полное издание проверялось многими аудиторами из числа членов itSMF. Детальное последнее редактирование издания книги было выполнено Карен Феррис (Karen Ferris) из компании KMF Advance. Принимая во внимание стремление к единодушию и согласию в области ITIL, мы будем рады новым разработкам, дополнительным материалам и другим творческим вкладам ITIL-профессионалов. Они будут обсуждаться редакторами и, в случае признания подходящими, будут включены в новые издания.


Ян Ван Бон,

главный редактор

Май, 2002 г.


Пожалуйста, направляйте Ваши комментарии об этом издании в редакторский коллектив книги по адресу: с/о Inform-IT, P.O. Box 23, 9841PA Grijpskerk, The Netherlands или по адресу электронной почты: jvbon@wxs.nl.

Глава 2 ИТ Сервис-менеджмент: общая картина

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

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

В этой главе уделяется внимание следующим понятиям:

? Услуги и качество: в разделе рассматриваются вопросы взаимосвязи Уровня Качества с точки зрения его восприятия заказчиками и пользователями, с Управлением Качеством, обеспечиваемым поставщиком (провайдером) ИТ-услуг.

? Организация и правила работы (policies): в разделе рассматриваются такие концептуальные понятия как представление компании о своей корпоративной цели (vision), стратегических задачах (objectives) и внутренней политике (правилах работы – policies), обсуждаются вопросы планирования корпоративной культуры и Управления Персоналом, а также координация бизнес-процессов компании с работой ИТ-служб.

? Управление Процессами: в данном разделе рассматриваются вопросы Управления Процессами ИТ Сервис-менеджмента.

2.1 Услуги и качество

Часто организации в значительной степени зависят от ИТ-услуг. Они ожидают, что ИТ-услуги будут не только поддержкой организации, но и дадут новые возможности для реализации целей бизнеса. Более того, ожидания заказчика могут существенно меняться со временем.

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

Предоставление ИТ-услуг охватывает все вопросы менеджмента ИТ-инфраструктуры, включая обслуживание и сопровождение.

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

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

Процесс предоставления услуги - это сочетание производства и потребления, в котором поставщик и заказчик участвуют одновременно.

Восприятие заказчика является существенным фактором при предоставлении услуг. Обычно заказчики задают себе следующие вопросы при оценке качества услуги:

? Отвечает ли услуга связанным с ней ожиданиями?

? Могу ли я ожидать получение такой же услуги в следующий раз?

? Предоставлена ли услуга по разумной цене?

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

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

Качество услуги – это показатель того, насколько услуга отвечает требованиям и ожиданиям заказчика. Для обеспечения качества поставщик должен постоянно оценивать, как услуга воспринимается заказчиком, и что клиент ожидает получить в будущем. Что для одного заказчика является обычным, для другого будет чем-то особенным. И в конечном итоге заказчик может привыкнуть к тому, что в самом начале считалось особенным. Результаты оценки можно использовать для определения того, нужно ли модифицировать услугу, предоставлять ли заказчику больше информации о ней или стоит изменить ее цену.

Качество – это совокупность характеристик продукта или услуги, которые формируют способность продукта удовлетворять сформулированные и подразумеваемые потребности (ISO-8402).

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

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

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

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

2.1.1. Гарантия качества

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

? Планирование (Plan): что нужно сделать, когда это нужно сделать, кто должен это сделать, как это следует сделать и с помощью чего.

? Выполнение (Do): выполнение запланированных работ.

? Проверка (Check): Определяется, дало ли выполнение работ ожидаемый результат.

? Действие (Act): производится корректировка планов с учетом информации, полученной на этапе проверки.

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



Рисунок 2.1. Цикл качества Деминга


Доктор Эдвард Деминг (Edward Deming) – американский статистик, которого компания General Douglas MacArthur направила в Японию после Второй мировой войны для восстановления разрушенной экономики. Он разработал теорию наиболее эффективного использования знаний и творческих возможностей в организациях США в 30-х годах прошлого века, но из-за Великой депрессии его идеи не были реализованы. Однако оптимизационные методы Деминга были успешно использованы в Японии.

Вот некоторые из положений теории Деминга:

? Заказчик является наиболее важной составляющей частью процесса производства.

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

? Ключ к достижению качества – уменьшение колебаний качества услуг и продукции.

? Разрушайте барьеры между подразделениями.

? Руководитель должен уметь взять на себя ответственность и быть лидером.

? Постоянно совершенствуйтесь.

? Создайте действенную программу обучения и самообучения.

? Организуйте обучение на рабочих местах.

? Преобразование[5] - задача каждого.

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

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

Система обеспечения качества – это организационная структура, определяющая распределение обя­занностей, используемые процедуры и ресурсы, необходимые для реализации Управления Качеством. Для разработки, оценки и усовершенствования системы обеспечения качества часто используются стандарты серии ISO-9000.

Стандарт качества ISO-9000:

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

ISO (International Organization for Standardization) – это международная организация по стандартизации. Система обеспечения качества, соответствующая стандарту ISO, гарантирует следующее:

? поставщик предпринимает меры по обеспечению качества, согласованного с заказчиками;

? руководство регулярно оценивает работу системы обеспечения качества и, по мере необходимо­сти, использует результаты внутреннего аудита для улучшения ее функционирования;

? процедуры работы поставщика задокументированы и переданы тем лицам, кто зависит от них;

? претензии заказчика регистрируются, рассматриваются в течение разумного срока и, по мере возможности, принимаются во внимание при усовершенствовании услуг;

? поставщик контролирует производственные процессы и может их совершенствовать.

Сертификат ISO не является абсолютной гарантией качества предоставляемых услуг, тем не ме­нее, он служит показателем серьезного отношения поставщика к вопросам обеспечения качества и его готовности обсуждать эти вопросы. Новые стандарты серии ISO-9000 – ISO-9000-2000 – по сравнению с предыдущими еще больше внимания уделяют спосо6ности организации извлекать уроки из полученного опыта и реализовывать на практике непрерывный процесс улучшения качества.

2.1.2. Организационная зрелость

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

Для определения зрелости организации можно использовать модель, разработанную Европейским фондом Управления Качеством (EFQM — European Foundation for Quality Management) (рис. 2.2). С помощью данной модели определяются основные сферы деятельности, которые следует прини­мать во внимание при Управлении Организацией.

Цикл качества Деминга входит составной частью в модель EFQM. Действия (определение страте­гии, курса движения организации) предпринимаются на основе результатов, полученных в тех областях, которые предполагают их получение. Такие действия являются фундаментом планирования (например, структуры процессов), целью которого является достижение желаемых результатов. Модель EFQM определяет девять сфер деятельности.


Рис. 2.2. Модель EFQM


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

Определено пять этапов:

? Нацеленность на продукт - этап, известный как ориентированный на результат; все в организации работают напряженно (но в этих усилиях отсутствует направленность); деятельность организуется специальным образом для каждого конкретного случая[6].

? Нацеленность на процесс – этап также известен под названием "мы знаем, что делаем"; деятельность организации имеет плановый и повторяющийся характер.

? Нацеленность на систему – или "сотрудничество подразделений".

? Нацеленность на цепочку[7] - этап также известен под названием "внешнее партнерство"; организация концентрирует усилия на том качестве, которое она добавляет как составляющий элемент к цепочке поставщик-заказчик.

? Нацеленность на всеобщее качество[8] - этап, называемый "рай на земле"; организация достигла такого уровня, когда постоянное и сбалансированное стремление к совершенствованию стало нормой.

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

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

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

В ИТ индустрии процесс развития Уровня Зрелости наиболее известен через Модель зрелости (Ca­pability Maturity Model – СММ). Эта модель была создана в институте разработки программного обеспечения (ПО) (Software Engineering Institute – SEI) в университете Карнеги-Меллона (Carnegie Mellon). Она предназначается для совершенствования процессов разработки ПО и повы­шения степени зрелости этих процессов. Модель СММ включает в себя следующие уровни:

? Начальный уровень – процессы выполняются индивидуально для каждого конкретного случая[9].

? Уровень Повторяющихся Процессов – процессы становятся повторяющимися и организованы таким образом, чтобы качество услуг стало повторяющимся.

? Уровень Документированных Процессов – процессы в организации документированы, стандар­тизованы и интегрированы.

? Уровень Управляемых Процессов – организация оценивает полученные результаты и использует их для повышения качества предоставляемых услуг.

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

На основе вышеперечисленных Уровней Зрелости процессов были разработаны модели ИТ Сервис-менеджмента.

Разрабатывая и сопровождая системы качества, отвечающие требованиям стандарта серии ISO-9000 (ISO-9000-2000), организация может достичь Уровня "Нацеленности на систему" (или Уровня "Уп­равляемых процессов" по терминологии модели СММ). Эти стандарты ISO уделяют основное вни­мание определению, описанию и проектированию процессов.


Рис. 2.3. Связи заказчик-поставщик и Уровни Зрелости


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

2.2. Организация и ее политика (правила работы)[10]

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

2.2.1. Корпоративная цель организации, ее миссия и правила

Организация – это определенная форма сотрудничества людей. Перед любой организацией, будь это дартс-клуб или мультинациональная компания, стоит вопрос: в чем цель объединения в организацию? Такой корпоративной целью (vision) может быть например, Ваше умение делать деньги, продавая персональные компьютеры. Но для того, чтобы организация стала привлекательной для всех заинтересованных сторон[11] (например, заказчиков, инвесторов, сотрудников компании и т.д.), вы должны уметь рассказать, почему им интересно иметь дело именно с вами. Может быть, вы самый лучший или самый дешевый поставщик или просто весельчак! Для этого вам следует создать привлекательный имидж. Здесь могут быть использованы такие лозунги, как "Давайте сделаем жизнь лучше!" или "Ты не будешь одинок!" и многие другие.

Для того чтобы сообщить всем свою корпоративную цель, компания может представить ее в виде тезиса о своей миссии (mission) (рис. 2.4.). Миссия – это короткое и четкое описание задач, стоящих перед организацией, и идеалов, в которые она верит.

Стратегические задачи (objectives) – это более подробное описание того, что хочет достичь организация. Хорошо сформулированные стратегические задачи должны обладать пятью основными свойствами (соответствовать принципу SMART): быть конкретными (Specific), поддаваться измерению (Measurable), быть уместными и соответствующими ситуации (Appropriate), быть реалистичными (Realistic) и иметь четкие временные границы (Time-bound).



Рис. 2.4. Корпоративная цель организации, ее стратегические задачи и политика (правила работы)


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

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

Для выполнения запланированных работ требуется осуществление определенных действий[12]. Для персонала действия определяются как задания[13], иногда их выполнение может передаваться сторон­ним организациям.

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

Таким образом необходимо измерять, в какой степени организация или процессы близки к достиже­нию своих стратегических целей. Для этого имеются различные методы. Одним из наиболее извест­ных в бизнесе методов является Карта Сбалансированных Оценок (Balanced Score Card – BSC). Согласно данному методу, на основе стратегических целей организации или целей процесса опреде­ляются критические факторы успеха (Critical Success Factor – CSF). Такие факторы формулиру­ются для нескольких наиболее важных сфер интересов компании, называемых перспективами (про­екциями)[14] организации: заказчики/рынок, бизнес-процессы, персонал/инновации и финансы. Клю­чевые показатели эффективности (Key Performance Indicators – KPI) являются теми параметра­ми, по которым определяется, достигли ли критические факторы успеха (CSF) заданного уровня. При необходимости ключевые показатели эффективности (KPI) могут быть подразделены на пока­затели эффективности (Performance Indicator – PI).

Ключевые показатели эффективности (KPI) – это параметры, используемые для измерения хода выполнения роботы по отношению к ключевым стратегическим целям организации или критическим факторам успеха (CSF).

Результаты измерений и изменяющиеся обстоятельства могут привести к модификации процессов, задач, планов и политики организации, а также к изменению стратегических задач (objectives), мис­сии (mission) и корпоративных целей организации (vision). Чем более зрелой является организация, тем легче она справляется с такими изменениями. Если ИТ-подразделение поддерживает интересы бизнеса, то стратегические задачи (objectives) ИТ-подразделения будут определяться стратегическими задачами бизнеса. Например, ИТ-подразделение может иметь стратегическую задачу: "Вно­сить свой вклад в усиление конкурентоспособности бизнеса". Задания подразделению будут теперь определяться, исходя из этой стратегической задачи. В зависимости от характера бизнеса, стратеги­ческие задачи для ИТ-подразделения будут ставиться с учетом надежности, доступности, скорости реагирования, технической сложности ИТ-решений и так далее.

2.2.2. Горизонт планирования[15]

Рассматривая политику и планирование работы ИТ-подразделения, необходимо учитывать связь планирования бизнеса в целом с планированием прикладных систем (приложений)[16] и технической инфраструктуры. При планировании коммуникационных сетей и приложений ИТ-подразделение должно находиться в авангарде общего планирования бизнеса, так как оно обеспечивает создание такой ИТ-инфраструктуры для бизнеса, благодаря которой он сможет развиваться.



Рис. 2.5. Горизонты планирования


У технической инфраструктуры самый дальний горизонт (период) планирования. Она выполняет поддерживающую роль и ее связи с реальной бизнес-деятельностью видны не всегда четко. На раз­работку инфраструктуры требуется время. Кроме того, зависимость информационных систем и биз­неса от технической инфраструктуры вносит ограничения на проведение ее изменений. Более того, разработка и создание инфраструктуры требует значительных инвестиций, и поэтому следует учи­тывать период ее амортизации.

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

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

? Время – самый легкий для определения показатель. Время определяется датой начала и оконча­ния работ, и очень часто разбивается на этапы.

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

? Качество – качество результата должно соответствовать поставленной цели.

? Затраты и доходы – результаты работы должны быть соразмерны предполагаемым затратам, уси­лиям и полученным доходам.

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

2.2.3. Корпоративная культура

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

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

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

2.2.4. Управление Персоналом[17]

Политика Управления Персоналом играет важную стратегическую роль в достижении организацией долгосрочных целей (также см. модель EFQM). Она также может быть использована в качестве ин­струмента изменения корпоративной культуры. Цель современного подхода к Управлению Персона­лом – оптимизация производительности работы всего персонала организации. Для этого использу­ются такие средства, как подбор кадров, обучение и продвижение по службе, мотивация труда и воз­награждение (поощрение).

Концепция HRM является основной формой современного Управления Персоналом. Концепция HRM основывается на двух предпосылках:

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

? Создание работникам организации условий для применения и развития своих способностей и на­выков послужит на пользу организации.

Существует три подхода к Управлению Персоналом:

? Жесткий подход – в этом случае людские ресурсы рассматриваются как средство производства. Они должны быть организованы наиболее эффективным и рациональным способом (effectively and efficiently). Как и корпоративная стратегия, политика управления персоналом определяется экономическими, техническими и рыночными условиями. При таком подходе значимость работников оценивается по-разному. Некоторые ключевые специалисты стратегически являются более важными, чем другие, вспомогательные работники, которым можно легко найти замену. Например, при таком подходе компания может принять решение, что только ключевые специалисты будут ра­ботать на постоянной основе, а все остальные – на контрактной.

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

? Интегрированный подход – такой подход строится на общих интересах персонала и руководства организации. Для достижения целей в организации должен быть нормальный приток, движение и отток кадров. Изменения на рынке и в организации (например, изменение в технологических областях) ведут к постоянным изменениям в спросе на различные специальности.

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

? Доведение политики организации до ее сотрудников – объяснение каждому сотруднику, в какой степени его работа способствует достижению целей, стоящих перед организацией. Важным усло­вием успеха в этом направлении является участие в нем всех уровней руководства.

? Оказание доверия, предоставление полномочий[18] – сотрудники получают возможность организо­вывать и выполнять свою работу по согласованию с организацией. Объем предоставляемых полно­мочий определяет Уровень Ответственности, которую сотрудники несут за качество выполненной работы.

? Ответственность[19] – результат применения двух первых пунктов. Если сотрудникам объяснили, чего от них ожидают, и если они имели возможность организовывать и выполнять свою работу так, как они считали нужным, то они несут полную ответственность за свою работу. Это может служить основой для оценки и вознаграждения сотрудников. Это вознаграждение может быть как матери­альным, так и нематериальным, например, признание или новые возможности для профессиональ­ного роста и развития карьеры и т. д.

? Управление Уровнем Компетенции[20] – является одновременно как средством наиболее эффектив­ного применения уже имеющихся в распоряжении организации знаний, так и способом системати­ческого развития знаний, необходимых для компании. Данный подход позволяет определять, ка­кой Уровень Компетенции требуется для выполнения необходимых процессов или проектов, а так­ же каким Уровнем Знаний должны обладать сотрудники. При организации работы персонала компания фокусируется не только на достижении нужного баланса между требуемым и существу­ющим Уровнем Компетенции сотрудников, но и на создании условий для развития компетенции, обмена знаниями и обучения новым навыкам. В этом сотрудникам могут помочь наставники[21]. Формирование коллективов сотрудников по областям знаний (по их специализации) способствует обмену опытом и появлению новых областей компетенции.

2.2.5. Управление Взаимоотношениями с Заказчиками ИТ-услуг[22]

Качество ИТ-услуг во многом зависит от взаимоотношений с заказчиками. На основе этих отноше­ний разрабатываются и корректируются Соглашения. Сферой действия Управления Отношениями с Заказчиками ИТ-услуг (IT Customer Relationship Management – CRM) является поддержание от­ношений с заказчиком и координация работы с организацией на стратегическом, тактическом и опе­рационном уровнях. На рис. 2.6 показаны горизонтальные контакты между заказчиками и ИТ-орга­низацией в плане поддержки отношений и координации работы. По вертикали отображены контак­ты по вопросам политики, контроля и отчетности.



Рис. 2.6. Управление Взаимоотношениями с Заказчиком ИТ-услуг


Основной задачей Управления Взаимоотношениями с Заказчиком ИТ-услуг (CRM) является обеспечение хороших и эффективных связей между ИТ-организацией и организацией заказчика на всех уровнях. Однако на каждом из этих роль CRM будет разной. Одним из элементов взаимоотношений является наличие Службы Service Desk, в то время как контроль над Уровнями Услуг может основываться на Процессе Управлением Уровня Сервиса[23] (SLM). В этих областях Управление взаимоотношениями с Заказчиками (CRM) играет вспомогательную роль, например, через организацию опросов заказчиков и пользователей, предоставление информации и т.д.

Пользователь – это человек "за компьютером", сотрудник, использующий услуги ИТ для выполнения повседневной работы.

Заказчик – это человек, "платящий по счетам", он имеет полномочия заключать Соглашение с ИТ-организацией на предоставление ИТ-услуг (например, Соглашение об Уровне Услуг – SLA) и отвечает за то, чтобы предоставленные услуги были оплачены.

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

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

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

Если заказчик хочет изменить (расширить или модифицировать) услуги, оговоренные в SLA, то он подает Запрос на Изменение[25] (RFC), который обрабатывается в рамках Процесса Управления Из­менениями (Change Management – CHG). Изменения, выходящие за рамки существующих догово­ренностей, передаются Процессу Управления Уровнем Услуг.

В то же время, в большинстве случаев по рабочим вопросам пользователи могут контактировать со службой Service Desk.

Рис. 2.6 дает представление не только о горизонтальных и вертикальных связях, но и о горизонте планирования процессов. У согласования на стратегическом уровне горизонт планирования состав­ляет несколько лет. Управление Уровнем Услуг связано с Соглашениями на тактическом уровне, где горизонт планирования равен приблизительно одному году. Управление Изменениями, Управление Инцидентами и Служба Service Desk занимается оперативными вопросами с горизонтом планирова­ния в несколько месяцев, недель, дней или даже часов.

2.3. Процессное управление

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

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

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

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

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

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

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

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


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

2.3.1. Процессы

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

Процесс – это логически взаимосвязанная между собой последовательность работ (видов деятельности[26]), направленная на достижение поставленной цели.

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

Стандарты для выходных данных каждого процесса должны быть определены таким образом, чтобы вся цепочка процессов обеспечивала достижение корпоративных стратегических целей. Если ре­зультат процесса отвечает заданному стандарту, такой процесс будет считаться эффективным (effec­tive). Если работы в рамках данного процесса к тому же выполняются с наименьшими усилиями и затратами, этот процесс будет рациональным (efficient)[27]. Цель Управления Процессами — планиро­вать и контролировать процессы таким образом, чтобы они были одновременно эффективными и рациональными.

Для оптимизации качества процессов каждый из них можно рассматривать отдельно. Владелец процесса несет ответственность за результаты работы процесса. Менеджер процесса отвечает за его структуру и выполнение и подотчетен владельцу процесса[28]. Координаторы процесса отвеча­ют за выполнение заданных видов работ и отчитываются о результатах их выполнения менедже­ру процесса.



Рис. 2.8. Общая диаграмма процесса


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

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

Часто процессы описывают с помощью процедур и рабочих инструкций.

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

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

На рис. 2.9 представлена модель процесса, созданная с использованием подхода ITIL. Эта модель является основой процессов ИТ Сервис-менеджмента, описанных в этой книге.



Рис. 2.9. Обобщенная модель процессов ITIL

2.3.2. Процессы и организационные подразделения

Большинство компаний имеют иерархическую структуру. Они состоят из подразделений, объединя­ющих группы сотрудников. Существуют разные принципы формирования подразделений, например, по типу заказчика, продукту, региону или области знания. Как правило, в предоставлении ИТ-услуг (сервисов) участвуют одновременно несколько отделов и затрагиваются несколько областей знаний. Например, если существует ИТ-сервис по предоставлению доступа к программе бухгалтерского уче­та на центральном компьютере, то в это будет вовлечено несколько подразделений. Вычислительный центр должен будет обеспечить доступ к программе и базе данных, служба передачи данных и телекоммуникаций будет обеспечивать связь с вычислительным центром, а подразделение поддержки персональных компьютеров - предоставлять пользователям интерфейс для доступа к программе.



Рис. 2.10. Процессы и организационные подразделения (пример)


В процессах, в которых участвует несколько подразделений, контроль качества услуг осуществляет­ся путем мониторинга определенных аспектов качества, например таких, как доступность, мощ­ность[30] ИТ-средств (пропускная способность), стоимость и стабильность. Затем ИТ-организация со­поставляет результаты мониторинга качества с потребностями заказчика. Структура таких процес­сов гарантирует получение качественной информации о предоставлении услуг, так, чтобы можно было совершенствовать контроль и планирование услуг.

2.3.3. ИТ Сервис-менеджмент

ИТ Сервис-менеджмент в первую очередь известен как ориентированный на процессы и услуги под­ход, который использовался в области, ранее известной как ИТ-менеджмент. В этой главе показано, что у процессов всегда должна быть определена цель. В свою очередь, цель процессов ИТ Сервис-менеджмента – содействовать повышению качества ИТ-услуг. Управление Качеством и контроль процессов являются частью организации и ее политики.

При процессно-ориентированном подходе необходимо учитывать ситуацию внутри организации (внутреннюю политику, корпоративную культуру, численность и так далее).

ITIL, наиболее известный подход к ИТ Сервис-менеджменту, не дает каких-либо ограничений по типу организации, а, наоборот, описывает связи между видами деятельности, составляющими процес­сы, которые применимы в организациях любого типа. Это создает структурированную основу[31] для обмена опытом между компаниями и изучения опыта динамично развивающихся организаций.

Глава 3 Введение в ITIL

В данной главе описывается структура и задачи библиотеки передового опыта организации ИТ (ITIL)[32] и приводятся сведения об организациях, способствующих превращению ITIL в лучший практический стандарт для ИТ Сервис-менеджмента.

3.1 Общая картина

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

В жизненном цикле ИТ-продуктов на их эксплуатацию приходится от 70 до 80% времени и финансовых средств, оставшаяся часть расходуется на разработку продукта (или их приобретение). Следовательно, для успешного использования ИТ существенное значение имеют эффективные и рациональные[33] Процессы Управления ИТ-услугами. Это относится к любому типу организаций, больших или малых, общественных или частных, с централизованными или децентрализованными ИТ-услугами, пользующихся аутсорсингом или работающих с внутренними ресурсами. В любом случае услуги должны быть надежными, согласующимися друг с другом, высококачественными и приемлемыми по стоимости.

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

ITIL предлагает структурированную основу[34] для организации всех видов деятельности в ИТ-подразделениях, являющихся частью оказания ИТ-услуг. Эти виды деятельности образуют процессы, составляющие основу для развития степени зрелости ИТ Сервис-менеджмента. Каждый из этих процессов решает одну или несколько задач ИТ-департамента, такие как разработка услуг (сервисов), Управление Инфраструктурой, предоставление и поддержка услуг. Такой процессный подход позволяет описать передовой опыт ИТ Сервис-менеджмента независимо от организационной структуры компании.

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

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

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

Ниже приводятся некоторые достоинства и недостатки библиотеки ITIL. Этот список не претендует на полноту, но позволяет оценить преимущества и недостатки ITIL, а также демонстрирует, как ITIL может быть использован организациями.

Преимущества библиотеки ITIL для заказчиков/пользователей:

? предоставление ИТ-услуг становится более ориентированным на заказчика, соглашения о качест­ве услуг способствуют улучшению взаимоотношений;

? услуги описываются лучше, на языке заказчика и с требуемой детализацией;

? лучше контролируются качество и стоимость услуг;

? улучшается взаимосвязь компании с ИТ-организацией за счет определения точек контактов.

Преимущества библиотеки ITIL для ИТ-организаций:

? становится четко понятна структура ИТ-департамента, его организация становится более рацио­нальной[35] и более ориентированной на корпоративные цели;

? руководство организацией становится более целенаправленным, облегчается Управление Измене­ниями;

? эффективная[36] структура процессов создает основу для эффективного аутсорсинга элементов ИТ-услуг;

? следование передовому опыту ITIL способствует изменению корпоративной культуры в направле­нии осознания, что задачей ИТ-департамента является предоставление услуг, и поддерживает вне­дрение системы обеспечения качества на основе стандартов серии ISO-9000;

? библиотека ITIL предоставляет единую "систему координат" и понятий для взаимодействия как в компании, так и с поставщиками, необходимую при разработке и стандартизации корпоративных процедур.

Возможные проблемы при работе с ITIL:

? переход на принципы ITIL может занять продолжительное время, потребовать значительных уси­лий и изменений в корпоративной культуре. Чересчур амбициозные планы при переходе на ITIL могут привести к разочарованию, и поставленные цели не будут достигнуты;

? если совершенствование структуры процессов становится самоцелью, может пострадать качество услуг. В этом случае процедуры становятся бюрократической преградой, которую сотрудники ста­раются по возможности избегать;

? улучшения не достигаются при недостатке понимания, что должны обеспечивать процессы (в чем их цель), что является критериями оценки эффективности процессов и как осуществлять их контроль;

? улучшения в предоставлении услуг и снижении стоимости недостаточно видны;

? успешная реализация требует вовлечения и наличие обязательств со стороны руководства и при­верженности сотрудников на всех организационных уровнях[37]. Предоставление права разработки структуры процессов специализированному подразделению может привести к его изоляции, в результате чего определенные им направления деятельности не будет приняты другими подраз­делениями;

? при недостаточных инвестициях в инструментальные средства (программное обеспечение и др.) про­цессы не будут работать должным образом и сервис не улучшится. Могут потребоваться дополнитель­ные ресурсы и персонал, если организация уже перегружена текущей рутинной работой.

Эти возможные проблемы, конечно, могут быть решены. Библиотека ITIL развивалась с целью дости­жения преимуществ для ИТ-организации и компании в целом. Многие из лучших практических пред­ложений направлены на предотвращение таких проблем или их решение в случае возникновения.

3.2. Организации

3.2.1. OGC (CCTA)

Библиотека ITIL первоначально была результатом работы Центрального агентства по вычислитель­ной технике и телекоммуникациям (Central Computer and Telecommunications Agency – CCTA) при правительстве Великобритании. В апреле 2001 г. ССТА было объединено с Государственной торго­вой палатой (Office of Government Commerce – OGC), являющейся в настоящее время новым вла­дельцем библиотеки ITIL Целью OGC является помощь заказчикам из государственного сектора экономики Великобритании в модернизации их деятельности по закупкам и улучшении обслужива­ния путем максимального использования ИТ и других инструментариев. "Задачей OGC является модернизация закупок правительственными службами и работа по улучшению использования фи­нансовых средств"[38]. OGC способствует использованию "передового опыта"[39] в различных сферах де­ятельности (например, Управление Проектами, Управление Закупками и ИТ Сервис-менеджмент). OGC выпускает несколько книжных серий (библиотек), написанных экспертами из Великобрита­нии и других стран мира, представляющими ряд компаний и организаций.

Принадлежащая OGC библиотека ITIL состоит из ряда доступных и детальных "Собраний практи­ческих руководств"[40] для предоставления эффективных и рациональных[41] ИТ-услуг (сервисов).

3.2.2. Форум itSMF

Форум по ИТ Сервис-менеджменту (Information Technology Service Management Forum – itSMF), ранее известный как Форум по менеджменту ИТ-инфраструктуры (Information Technology Infrastructure Man­agement Forum – ITIMF) является единственной имеющей международное признание независимой группой пользователей[42], занимающейся вопросами ИТ Сервис-менеджмента. Ее единственными вла­дельцами и управляющими являются члены группы. Форум itSMF оказывает определяющее влияние и делает вклад в популяризацию передового опыта и разработку стандартов во всем мире. Первая региональная организация itSMF возникла в Великобритании в 1991 г. Следующей была голландская (itSMF — The Netherlands), учрежденная в Нидерландах в 1993 г. Сейчас отделения фо­рума itSMF есть в таких странах, как ЮАР, Бельгия, Германия, Австрия, Швейцария, Канада, США и Австралия; все они сотрудничают в рамках форума itSMF International. Сайты этих отделений указаны в приложении В2.

Региональные отделения itSMF способствуют обмену информацией и опытом, что позволяет ИТ-организациям повысить качество поставляемых услуг. Они организуют семинары, конференции, об­суждения отдельных тем и другие мероприятия, посвященные современным проблемам ИТ Сервис-менеджмента. Кроме того, они издают информационные бюллетени и используют Web-сайты для обмена информацией. Рабочие группы[43] способствуют дальнейшему развитию библиотеки ITIL.

3.2.3. Организации EXIN и ISEB

Голландская организация "Exameninstituut voor Informatica" (EXIN) и британская "Information Sys­tems Examination Board" (ISEB) совместно разработали профессиональную систему сертификации в рамках библиотеки ITIL. Разработка проводилась в тесном сотрудничестве с OGC и itSMF. EXIN и ISEB являются некоммерческими организациями, сотрудничающими для разработки всего диапа­зона квалификационных сертификатов ITIL трех уровней:

? базовый сертификат по ИТ Сервис-менеджменту – Foundation Certificate in IT Service Management,

? сертификат специалиста по ИТ Сервис-менеджменту – Practitioner Certificate in IT Service Man­agement;

? сертификат менеджера по ИТ Сервис-менеджменту – Manager Certificate in IT Service Management.

Система сертификации основана на требованиях по эффективному выполнению соответствующей роли в ИТ-организации. К настоящему времени базовые сертификаты получили более 50 000 про­фессионалов ИТ из более чем 30 стран.

Базовый сертификат предназначен для всего персонала, который должен быть в курсе главных задач ИТ-организации и их взаимосвязи. Экзамен на получение базового сертификата включает оценку знаний Службы Service Desk и Процессов Управления Инцидентами, Проблемами, Изменениями, Конфигурациями, Релизами, Уровнем Услуг, Доступностью, Мощностями, Непрерывностью ИТ-ус­луг и Финансами ИТ. После получения базового сертификата разрешается сдавать экзамены на по­лучение сертификата специалиста и менеджера. Специалисты получают навыки практического осу­ществления отдельных ITIL-процессов и задач в рамках таких процессов, как Управление Инциден­тами, Изменениями и Уровнем Услуг. Менеджеры получают теоретические знания о том, как управ­лять всеми процессами, перечисленными в базовом сертификате, как консультировать по структуре и оптимизации процессов и как осуществлять внедрение этих процессов.

Сегодня библиотека ITIL представляет собой гораздо большее, чем серию полезных книг по ИТ Сервис-менеджменту. В практический опыт ITSM в настоящее время входит вся индустрия, вклю­чающая организации, инструментарии (специализированное программное обеспечение), тренинговые и консалтинговые услуги, соответствующие методологические основы[44] и публикации. С 90-х го­дов библиотека ITIL считается уже не только структурированной основой, но также подходом и фи­лософией, разделяемой теми, кто использует в своей работе передовой опыт ITIL. В настоящее вре­мя ряд организаций ведут международное сотрудничество для продвижения библиотеки ITIL как признанного "де факто" стандарта ИТ Сервис-менеджмента.



Рис. 3.1. Среда ITIL (источник OGC).


На рис. 3.1 среда ITIL показывает, что привлеченные организации предоставляют обратную связь между текущей практикой (светлые эллипсы) и теорией (темные эллипсы) для поддержания актуаль­ности библиотеки ITIL. Более того, разработаны расширения и альтернативные решения, отдельные из которых могут рассматриваться как самостоятельные методы ИТ Сервис-менеджмента. Эти аль­тернативные решения часто рассматривают вопросы определенных групп пользователей или орга­низаций, специфические проблемы которых не находят адекватного отражения в ITIL. Уникальной особенностью библиотеки ITIL является то, что она предлагает общую основу[45], базиру­ющуюся на практическом опыте профессиональных пользователей по всему миру.

3.3. Книги библиотеки ITIL

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

Библиотека ITIL определяет цели и виды деятельности, входные и выходные параметры каждого из процессов в ИТ-организации. Однако, библиотека ITIL не дает конкретного описания способов осу­ществления этой деятельности, так как они могут различаться в каждой организации. Акцент дела­ется на проверенном практикой подходе, который может быть реализован различными способами в зависимости от обстоятельств. Библиотека ITIL не является методом; наоборот, она предлагает структурированную основу для планирования наиболее часто используемых процессов, ролей и ви­дов деятельности, определяя связи между ними и необходимые виды коммуникации. Создание библиотеки ITIL вызвано необходимостью предоставления высококачественных услуг, уделяя при этом особое внимание отношениям с заказчиком. ИТ-организация должна выполнять соглашения с заказчиком, что означает поддержание хороших отношений с заказчиками и партнера­ми, такими, как поставщики.

Частично философия библиотеки ITIL имеет в своей основе системы качества, такие, как стандарты серии ISO-9000, и общие схемы обеспечения качества (Total Quality frameworks), как предлагаемые Европейской организацией Управления Качеством (European Foundation of Quality Management – EFQM). Библиотека ITIL поддерживает эти системы путем предоставления четкого описания про­цессов и передового опыта ИТ Сервис-менеджмента. Это может значительно сократить время, необ­ходимое для прохождения сертификации ISO.

Первоначально библиотека ITIL состояла из нескольких комплектов книг, в каждом из которых описывалась конкретная область сопровождения и эксплуатации ИТ-инфраструктуры. Ядром ITIL считались десять книг, в которых описывались такие области, как поддержка услуг[46] и предоставле­ние услуг[47]. Библиотека включала также около 40 других книг по вспомогательным предметам, имев­шим отношение к ИТ Сервис-менеджменту, от монтажа кабелей до Управления Отношениями с За­казчиком. Однако, в первоначальных сериях книг вопросы ИТ Сервис-менеджмента рассматривали главным образом с точки зрения ИТ. Для заполнения разрыва между бизнес-практикой и ИТ-организацией в библиотеку была включена серия книг, рассматривающая бизнес-аспекты ИТ Сервис-менеджмента[48]. Более того, в определенных частях библиотеки ITIL в то время использовался не­сколько устаревший подход.

В настоящее время была сделана переработка центральных книг по ITIL и они были переизданы в виде двух книг: одна – по поддержке услуг и другая – по их предоставлению. Это позволило исклю­чить повторы и встречавшуюся местами несогласованность ранних серий, что улучшило структур­ное единство издания, которое теперь дает более четкое представление об ИТ Сервис-менеджменте.

Начатый после выпуска указанного издания пересмотр всей серии публикаций ITIL еще не завершен.


Рис. 3.2. Представление элементов библиотеки ITIL (Источник: OGC)

Структурированный подход, изложенный в библиотеке ITIL, состоит из семи элементов (см. рис. 3.2). Все элементы взаимодействуют между собой и в определенной степени перекрываются друг с другом.

Этими элементами являются:

? Поддержка услуг (Service Support) – публикация 2000 г.;

? Предоставление услуг (Service Delivery) – публикация 2001 г.;

? Управление Инфраструктурой информационных и коммуникационных технологий (ICT Infra­structure Management) – публикация 2002 г.;

? Управление Приложениями (Applications management) – публикация 2002 г.;

? Управление Безопасностью (Security management) – публикация 2002 г.;

? Планирование внедрения Сервис-менеджмента (Planning to Implement Service Management) – публикация 2002 г.;

? Бизнес-перспектива (The Business Perspective) – публикация планируется в 2004 г.

В этой главе мы представляем серии публикаций ITIL. В течение 2002 г. оригинальная серия, пер­вые книги которой появились в 1989 г., была заменена шестью новыми книгами ITIL, издание седьмой книги планируется на 2004 г. Более подробная информация по этой теме приводится в при­ложении и на Web-сайтах OGC и EXIN.

3.3.1. Предоставление услуг

Как уже отмечалось, Поддержка услуг и Предоставление услуг считаются центральными компонен­тами передового опыта ITIL для ИТ Сервис-менеджмента.

В книге ITIL по Предоставлению услуг описываются требования, необходимые для оказания услуг. В этой серии рассматриваются следующие вопросы:

? Управление Уровнем Услуг;

? Управление Финансами ИТ;

? Управление Мощностями;

? Управление Непрерывностью ИТ-услуг;

? Управление Доступностью.

В данную ознакомительную книгу было включено также Управление Информационной Безопасно­стью (со ссылкой на книгу ITIL по информационной безопасности), но оно не является частью се­рии по предоставлению услуг.

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



Рис. 3.3. Поддержка и Предоставление Услуг.


Управление Уровнем Услуг

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

Управление Уровнем Услуг рассматривает услуги, предоставляемые заказчику (с акцентом на заказчике[49]). ИТ-организация может повысить степень удовлетворенности заказчика через создание услуг за основе его потребностей (услуги, вызванные спросом[50]), только на базе своих технических возможностей (услуги, вызванные предложением[51]). В главе об Управлении Уровнем Услуг книги по Предоставлению услуг рассматриваются следующие вопросы:

? как оптимизировать ИТ-услуги для их предоставления заказчикам по доступным ценам на основе точного определения договоренностей в Соглашении об Уровне Услуг;

? как проводить мониторинг и обсуждение услуг;

? как организовать Поддержку Услуг Внешними Договорами[52] с поставщиками.

Управление Финансами ИТ

Управление Финансами касается экономических вопросов предоставляемых ИТ-услуг. Например, Процесс Управления Финансами подготавливает информацию о расходах, возникших при предоста­влении услуг. В результате при определении необходимых изменений ИТ-инфраструктуры или ИТ-услуг возможен учет финансовых факторов (соотнесение расходов и доходов – цены и результата). Определение, отнесение расходов, их прогноз и отслеживание, рассматривавшиеся в главе об управ­лении финансами книги по предоставлению услуг, - все это охватывается термином "расчет себестоимости"[53], а в нынешнем издании ITIL называется "бюджетированием и бухгалтерским учетом". Эта деятельность повышает информированность о расходах (где возникают издержки и какие) и может использоваться также при составлении бюджета. Управление Финансами ИТ описывает различные методы выставления счетов, включая определение цели выставления счетов за ИТ-услуги (для чего это используется в компании?) и определение ценообразования, а также аспекты бюджетирования.

Управление Мощностями

Управление Мощностями представляет собой процесс оптимизации расходов, времени приобретения и размещения ИТ-ресурсов с целью обеспечения выполнения договоренностей с заказчиком. Процесс Уп­равления Мощностями имеет дело с Управлением Ресурсами, Управлением Производительностью, Упра­влением Спросом на ИТ, моделированием, планированием мощностей, Управлением Нагрузкой и опреде­лением необходимого объема технических средств для работы приложений[54]. В Управлении Мощностями акцент делается на планировании для обеспечения согласованного Уровня Услуг сейчас и в будущем.

Управление Доступностью

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

Управление Непрерывностью ИТ-услуг

Этот процесс касается подготовки и планирования способов устранения чрезвычайных ситуаций с ИТ-услугами в случае остановки бизнеса. Называвшийся в предыдущем издании ITIL "Планирова­нием на случай чрезвычайных обстоятельств"[55], этот процесс уделяет основное внимание связям ме­жду всеми компонентами, необходимым для защиты непрерывности деятельности компании при ка­тастрофах (т. е. для Управления Непрерывностью Бизнеса), а также средствам предотвращения та­ких катастроф. Управление Непрерывностью ИТ-услуг является процессом планирования и коор­динации технических, финансовых и управленческих ресурсов, необходимых для обеспечения не­прерывности услуг после катастроф, в соответствии с договоренностью с заказчиком.

3.3.2. Поддержка услуг

В книге ITIL по поддержке услуг описывается, как заказчик может получить доступ к соответствую­щим услугам для поддержки своего бизнеса. Эта книга охватывает следующие области:

? Служба Service Desk;

? Управление Инцидентами;

? Управление Проблемами;

? Управление Конфигурациями;

? Управление Изменениями;

? Управление Релизами.

Служба Service Desk

Служба Service Desk является точкой контакта пользователя с ИТ-организацией. Ранее в книгах ITIL она называлась службой Help Desk. Основными задачами службы Help Desk были регистра­ция, решение и отслеживание инцидентов. Служба Service Desk имеет более широкие функции (на­пример, получение Запросов на Изменения) и может выполнять действия, относящиеся к несколь­ким процессам.

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

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

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

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

Когда причины установлены (определены известные ошибки), принимается бизнес-решение о том, необходимо ли делать улучшения в инфраструктуре для предотвращения возникновения новых ин­цидентов. Такие улучшения производятся путем подачи Запросов на Изменение[56]. Необходимо обратить внимание на то, что определение Управления Проблемами, дающееся в ITIL, зна­чительно отличается от определения, которое раньше было принято, например, в ИТ-индустрии США.

Управление Конфигурациями

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

Управление Изменениями

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

Управление Релизами

Релизом называется набор Конфигурационных Единиц[57], которые совместно тестируются и вводятся в активную рабочую среду. Главной задачей Управления Релизами является обеспечение успешного развертывания релизов, включая интеграцию, проведение тестирования и хранение.

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

3.3.3. Другие рассматриваемые процессы

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

Управление Взаимоотношениями с Заказчиком ИТ

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

Управление Информационной Безопасностью

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



Рис. 3.4. Книга "Поддержка Услуг" (Service Support) – публикация 2000 г. (OGC)



Рис. 3.5. Книга "Предоставление Услуг" (Service Delivery) – публикация 2001 г. (OGC)



Рис. 3.6. Книга "Управление Инфраструктурой информационных и коммуникационных технологий" (ICT Infrastructure Management) – публикация 2002 г. (OGC)



Рис. 3.7. Книга "Управление Приложениями" (Application Management) – публикация 2002 г. (OGC)



Рис. 3.8. Книга "Управление Безопасностью" (Security Management) – публикация 2002 г. (OGC)



Рис. 3.9. Книга "Планирование внедрения Сервис-менеджмента" (Planning to Implement Service Management) – книга 2002 г. (OGC)

Глава 4 Управление Инцидентами

4.1. Введение

Задача Процесса Управления Инцидентами является реактивной – уменьшение или исключение отрицательного воздействия (потенциальных) нарушений в предоставлении ИТ-услуг, таким образом обеспечивая наиболее быстрое восстановление работы пользователей. Для выполнения этой задачи производится регистрация, классификация и назначение инцидентов соответствующим группам специалистов, мониторинг хода работ по разрешению инцидентов, решение инцидентов и их закрытие. Так как это требует тесного взаимодействия с пользователями, фокусной точной Процесса управления Инцидентами обычно является функция Service Desk[58], которая играет роль центра контактов пользователей с "внутренними" коллективами технических служб. Управление Инцидентами является важнейшей основой для работы других процессов ITIL, предоставляя ценную информацию об ошибках в работе ИТ-инфраструктуры.

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



Рис. 4.1. Позиционирование Процесса Управления Инцидентами относительно других функций (подразделений) ИТ-организации

4.1.1. Терминология

Инцидент

Библиотека ITIL использует широкое определение термина "инцидент", поэтому почти все обращения пользователей могут регистрироваться и отслеживаться как инциденты.

В книге "Поддержка услуг" библиотеки ITIL дается следующее определение:

Инцидент[59] - это любое событие, не являющееся частью стандартных операций по предоставлению услуги, которое привело или может привести к нарушению или снижению качества этой услуги.

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

Запрос на обслуживание[60] - это Запрос от Пользователя на поддержку, предоставление информации, консультации или документации, не являющийся сбоем ИТ-инфраструктуры.

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

? вопрос о функционировании ИТ-систем или запрос о предоставлении какой-либо информации;

? запрос о состоянии (статусе) чего-либо в ИТ-инфраструктуре;

? запрос о замене пароля;

? запросы на выполнение пакетных заданий, восстановление или авторизацию пароля;

? получение информации из базы данных.

Для того чтобы можно было отличить "настоящие инциденты" от "инцидентов-Запросов на Обслу­живание", рекомендуется присваивать Запросам на Обслуживание специальную категорию. Важно также отметить, что Запрос на Обслуживание это не то же самое, что Запрос на Изменение:

Запрос на Изменение (RFC)[61] – это экранная или бумажная форма, используемая для записи деталь­ной информации о предлагаемом Запросе на Изменение какой-либо Конфигурационной Единицы[62] (CI) в ИТ-инфраструктуре или процедуры или какого-либо иного объекта ИТ-инфраструктуры.

Запрос на Изменение RFC считается завершенным после проведения изменения в инфраструктуре, например, замены зарегистрированных компонентов, инсталляции ПК и т. д. Это не инциденты, а изменения.

Степень воздействия[63], срочность[64] и приоритет[65]

При одновременной обработке нескольких инцидентов необходимо расставлять приоритеты. Обос­нованием для назначения приоритета служит уровень важности ошибки для бизнеса и для пользо­вателя. На основе диалога с пользователем и в соответствии с положениями Соглашений об Уров­нях Услуг (Service Level Agreements – SLAs) Служба Service Desk назначает приоритеты, определя­ющие порядок обработки инцидентов. При эскалации инцидентов на вторую, третью или более ли­нии поддержки, тот же приоритет должен быть соблюден, но иногда он может быть скорректирован по согласованию со Службой Service Desk.

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

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

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

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

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


Рис. 4.2. Определение степени воздействия, срочности и приоритета


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

Степень воздействия и срочность могут быть объединены в матрицу, как показано в табл. 4.1.


Приоритет Высокая Средняя Низкая
Время разрешения
Высокая Критический Высокий Средний
< 1 часа < 8 часов < 24 часов
Средняя Высокий Средний Низкий
< 8 часов < 24 часов < 48 часов
Низкая Средний Низкий Планирование
< 24 часов < 48 часов Запланировано

Таблица 4.1. Пример системы кодирования приоритетов


Эскалация

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

Различают функциональную и иерархическую эскалацию:

? Функциональная эскалация (горизонтальная) – означает привлечение большего количества специалистов или предоставление дополнительных прав доступа для разрешения инцидента; при этом, возможно, происходит выход за пределы одного структурного ИТ-подразделения.

? Иерархическая эскалация (вертикальная) – означает вертикальный переход (на более высокий уровень) в рамках организации, так как для разрешения инцидента недостаточно организационных полномочий (уровня власти) или ресурсов.

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

Первая, вторая и n-линия поддержки

Выше была изложена маршрутизация инцидента, или функциональная эскалация. Маршрутизация определяется требуемым уровнем знаний, полномочий и срочностью. Первой линией поддержки (называемой также поддержкой 1-го уровня) обычно является Служба Service Desk, второй линией – подразделений, осуществляющие Управление ИТ-инфраструктурой, третья – отделы разработки и архитектуры программного обеспечения, и четвертая – поставщики. Чем меньше организация, тем меньше в ней уровней эскалации. В больших организациях Руководитель Процесса Управления Инцидентами может назначить Координаторов инцидентов в соответствующих подразделениях для поддержки своей деятельности. Например, координаторы могут играть роль интерфейса между процессной деятельностью и линейными организационными подразделениями. Каждый из них координирует деятельность собственных групп поддержки. Процедура эскалации графически представлена на рис. 4.3.



Рис. 4.3. Эскалация инцидента (источник: OGC)


4.2. Цель

Целью Процесса Управления Инцидентами является скорейшее восстановление нормального Уров­ня Услуг, определенного в Соглашении об Уровне Услуг (Service Level Agreement – SLA), с мини­мальными возможными потерями для бизнес-деятельности организации и пользователей. Кроме то­го, Процесс Управления Инцидентами должен вести точную регистрацию инцидентов для оценки и совершенствования процесса и предоставления необходимой информации для других процессов.

4.2.1. Преимущества использования процесса

? Для бизнеса в целом:

? своевременное разрешение инцидентов, ведущее к уменьшению потерь для бизнеса;

? повышение производительности работы пользователей;

? независимый, ориентированный на потребности заказчика мониторинг инцидентов;

? доступность объективной информации о соответствии предоставляемых услуг согласованным договоренностям (SLA).

? Для ИТ-организации:

? улучшенный мониторинг, позволяющий проводить точное сопоставление уровня производи­тельности ИТ-систем с соглашениями (SLA);

? эффективное руководство и мониторинг выполнения соглашений (SLA) на основе достоверной информации;

? эффективное использование персонала;

? предотвращение потерь инцидентов и Запросов на Обслуживание или их неправильной регистрации;

? повышение точности информации в Конфигурационной Базе Данных (Configuration Manage­ment Database – CMDB) за счет ее проверки при регистрации инцидентов в привязке к Конфи­гурационным Единицам (Configuration Item – CI);

? повышение удовлетворенности пользователей и заказчиков.

Отказ от использования Процесса Управления Инцидентами может привести к следующим отрицательным последствиям:

? инциденты могут быть потеряны или, наоборот, необоснованно восприняты как чрезвычайно серьезные из-за отсутствия ответственных за мониторинг и эскалацию, что может привести к сни­жению общего уровня обслуживания;

? пользователи могут перенаправляться к одним и тем же специалистам "по кругу" без успешного разрешения инцидента;

? специалисты могут постоянно отрываться от работы телефонными звонками пользователей, из-за чего им становится трудно эффективно выполнять свою работу;

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

? может ощущаться недостаток информации о пользователях и предоставляемых услугах, необходи­мой для принятия руководящих решений;

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

4.3. Процесс

На рис. 4.4 показаны входы и выходы процесса, а также виды деятельности, которые охватывает этот процесс.



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


4.3.1. Входы процесса

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

4.3.2. Управление конфигурациями

Конфигурационная База Данных (Configuration Management Database - CMDB) играет важную роль в Управлении Инцидентами, так как она определяет связь между ресурсами, услугами, пользо­вателями и Уровнями Услуг (сервисов). Например, Управление Конфигурациями показывает, кто является ответственным за компонент инфраструктуры, что делает возможным более эффективное распределение инцидентов по группам специалистов. Кроме того, эта база данных помогает решать оперативные вопросы, например, перенаправление очереди печати или переключение пользователя на другой сервер. При регистрации инцидента в регистрационные данные добавляется связь (link) с соответствующей Конфигурационной Единицей (Configuration Item – CI), позволяющая предоста­вить более подробную информацию об источнике ошибки. В случае необходимости может быть об­новлен статус соответствующей компоненты в CMDB.

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

Эффективное Управление Проблемами требует качественной регистрации инцидентов, что значи­тельно облегчит поиск корневых причин. С другой стороны, Управление Проблемами помогает Процессу Управления Инцидентами, предоставляя информацию о проблемах, известных ошибках, обходных решениях и быстрых исправлениях[66].

4.3.4. Управление Изменениями

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

4.3.5. Управление Уровнем Услуг

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

4.3.6. Управление Доступностью

Для определения показателей доступности услуг Процесс Управления Доступностью использует ре­гистрационные данные об инцидентах и данные мониторинга статуса, предоставляемые Процессом Управления Конфигурациями. Аналогично Конфигурационной Единице (CI) в Конфигурационной Базе Данных (CMDB), сервису (услуге) может быть также назначен статус "не работает"[67]. Это мо­жет быть использовано для проверки действительных показателей доступности услуги и времени реагирования поставщика. При осуществлении такой проверки необходима фиксация времени дей­ствий, произошедших в процессе обработки инцидента, от момента обнаружения и до закрытия.

4.3.7. Управление мощностями

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

Ни рис. 4.5. показаны этапы процесса:



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


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

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

? Если вызов касается Запроса на Обслуживание (Service Request), то инициируется соответствующая процедура.

? Привязка (или сопоставление – Matching) – проверяется, не является ли инцидент уже извест­ным инцидентом или известной ошибкой, нет ли для него уже открытой проблемы, и нет ли для него известного решения или обходного пути.

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

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

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

? Мониторинг хода работ и отслеживание (Progress monitoring and Tracking) – весь цикл обработ­ки инцидента контролируется, и если инцидент не может быть разрешен вовремя, производится эскалация.

4.4. Виды деятельности

4.4.1. Прием и регистрация

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

? трудно произвести точную регистрацию информации об инциденте, если это не сделано сразу;

Загрузка...