Главная Учебники - Разные Лекции (разные) - часть 18
поиск по сайту правообладателям
|
ИТ СЕРВИС–МЕНЕДЖМЕНТ. Вводный курс на основе ITIL
Введение в ИТ СЕРВИС-МЕНЕДЖМЕНТ http://lib.rus.ec/b/131430/read здесь лучше http://www.yax.su/finlab/ir081/8/index.shtml Содержание
ИТ СЕРВИС–МЕНЕДЖМЕНТ. Вводный курс на основе ITIL.. 1
Глава 2 ИТ Сервис-менеджмент: общая картина. 8
2.1.2. Организационная зрелость. 11
2.2. Организация и ее политика (правила работы) 13
2.2.1. Корпоративная цель организации, ее миссия и правила. 13
2.2.2. Горизонт планирования 16
2.2.3. Корпоративная культура. 17
2.2.4. Управление Персоналом 18
2.2.5. Управление Взаимоотношениями с Заказчиками ИТ-услуг 19
2.3. Процессное управление. 20
2.3.2. Процессы и организационные подразделения. 23
2.3.3. ИТ Сервис-менеджмент. 24
3.2.3. Организации EXIN и ISEB.. 26
3.3. Книги библиотеки ITIL.. 27
3.3.1. Предоставление услуг. 29
Глава 4 Управление Инцидентами. 32
4.2.1. Преимущества использования процесса. 35
4.3.2. Управление конфигурациями. 36
4.3.3. Управление Проблемами. 36
4.3.4. Управление Изменениями. 36
4.3.5. Управление Уровнем Услуг. 37
4.3.6. Управление Доступностью.. 37
4.3.7. Управление мощностями. 37
4.4.1. Прием и регистрация. 39
4.4.3. Привязка (сопоставление) 40
4.4.4. Расследование и диагностика. 40
4.4.5. Решение и восстановление. 40
4.4.7. Мониторинг хода решения и отслеживание. 40
4.5.1. Критические факторы успеха. 41
4.5.2. Показатели эффективности 41
Глава 5 Управление Проблемами. 42
5.1.1. Определение – "проблема" и "известная ошибка". 43
5.1.2. Взаимоотношения с Процессом Управления Инцидентами. 43
5.3.1. Управление Инцидентами. 45
5.3.2. Управление Изменениями. 46
5.3.3 Управление Конфигурациями. 46
5.3.4. Управление Доступностью.. 46
5.3.5. Управление Мощностями. 46
5.3.6. Управление Уровнем Услуг. 46
Глава 6. Управление Конфигурациями. 52
6.2.1. Преимущества использования процесса. 54
6.3.1. Управление Инцидентами. 55
6.3.2. Управление Проблемами. 55
6.3.3. Управление Изменениями. 55
6.3.4. Управление Релизами. 56
6.3.5. Управление Уровнем Услуг. 56
6.3.6. Управление Финансами. 56
6.3.7. Управление Доступностью.. 56
6.3.8. Управление Непрерывностью ИТ-услуг. 56
6.3.9. Управление Мощностями. 56
6.4.5. Верификация и аудит. 64
6.5.1. Отчеты и Ключевые показатели эффективности. 64
6.5.2. Критические факторы успеха. 64
Глава 7 Управление Изменениями. 66
7.2.1. Преимущества использования процесса. 68
7.3.1. Управление Инцидентами. 69
7.3.2. Управление Конфигурациями. 69
7.3.3. Управление Проблемами. 69
7.3.4. Управление Релизами. 69
7.3.5. Управление Уровнем Сервиса. 69
7.3.6. Управление Доступностью.. 69
7.3.7. Управление Мощностями. 69
7.3.8. Управление Непрерывностью ИТ-услуг. 69
7.3.9. Виды деятельности в рамках Процесса Управления Изменениями. 70
7.4.7. Проведение срочных изменений. 76
7.5.1 Отчеты для руководства. 76
Глава 8 Управление Релизами. 77
8.2.1. Преимущества использования процесса. 81
8.3.1. Управление Конфигурациями. 82
8.3.2. Управление Изменениями. 82
8.3.3. Управление Уровнем Услуг. 82
8.4.1. Выработка политики в отношении релизов и планирование. 83
8.4.2. Проектирование, компоновка и конфигурирование. 83
8.4.3. Тестирование и приемка релиза. 84
8.4.4. Планирование внедрения. 85
8.4.5. Оповещение, подготовка и обучение. 85
8.4.6. Распространение релизов и инсталляция. 85
Глава 9 Служба Service Desk. 86
9.3.3. Варианты организации Службы Service Desk. 88
9.3.4. Персонал Службы Service Desk. 89
9.3.5. Технологии для работы Службы Service Desk. 90
9.4.3. Взаимодействие с поставщиками. 91
9.4.4. Операционные задачи. 91
9.4.5. Мониторинг инфраструктуры.. 91
9.5.2. Критические факторы успеха. 92
Глава 10 Управление Уровнем Сервиса (Услуг) 92
10.5.1. Критические факторы успеха и ключевые показатели эффективности. 101
10.5.2. Отчеты руководству 101
10.6. Проблемы и затраты.. 102
Глава 11 Управление Финансами ИТ. 102
11.4.1. Составление бюджета. 107
11.4.2. Бухгалтерский учет. 108
11.4.3. Выставление счетов. 110
11.5.1. Отчеты для руководства. 111
11.6. Проблемы и затраты.. 112
Глава 12 Управление Мощностями. 112
12.4.1. Управление Возможностями Бизнеса (Business Capacity Management) 116
12.5.1. Отчеты для руководства. 118
12.5.2. Критические факторы успеха и Ключевые Показатели Эффективности (КPI) 118
12.6. Проблемы и затраты.. 119
Глава 13 Управление Непрерывностью ИТ-сервисов. 120
13.4.1. Определение охвата (области действия) Процесса Управления Непрерывностью ИТ-сервисов. 122
13.4.2. Анализ воздействия на бизнес 123
13.4.4. Стратегия обеспечения непрерывности ИТ-сервисов. 124
13.4.5. Организация процесса и планирование внедрения. 126
13.4.6. Применение превентивных мер и способов восстановления. 127
13.4.7. Разработка планов и процедур восстановления. 127
13.4.8. Начальное тестирование. 128
13.4.9. Обучение и осведомление. 128
13.4.12. Управление Изменениями. 128
13.4.13. Обеспечение гарантий 128
13.5. Управление Процессом.. 128
13.5.1. Отчеты для руководства. 129
13.5.2. Критические факторы успеха и ключевые показатели качества. 129
13.6. Проблемы и затраты.. 129
Глава 14 Управление Доступностью.. 130
14.2.1. Преимущества использования процесса. 132
14.4.1. Определение требований к доступности сервиса. 134
14.4.2. Проектирование систем для достижения требуемого Уровня Доступности. 134
14.4.3. Проектирование систем для достижения требуемого Уровня Обслуживания. 134
14.4.4. Ключевые вопросы безопасности. 134
14.4.5. Управление Обслуживанием.. 134
14.4.6. Проведение измерений и составление отчетов. 135
14.4.7. Разработка Плана Обеспечения Доступности. 136
14.4.8. Инструментальные средства. 136
14.4.9. Методы и методики. 136
14.5.1. Составление отчетов. 139
14.5.2. Критические факторы успеха и ключевые показатели эффективности. 139
14.6. Проблемы и затраты.. 139
Глава 15 Управление Информационной Безопасностью.. 140
15.2.1. Преимущества использования процесса. 142
15.3.1. Взаимоотношения с другими процессами. 143
15.3.2. Раздел по Безопасности Соглашения об Уровне Сервиса. 146
15.3.3. Раздел по Безопасности Операционного Соглашения об Уровне Услуг (OLA) 148
15.4.1. Контроль – политика и организация информационной безопасности. 148
15.4.6. Составление отчетов. 150
15.5.1. Критические факторы успеха и ключевые показатели эффективности. 151
15.6. Проблемы и затраты.. 151
А.1. Управление Конфигурациями. 153
A.3. Управление Проблемами. 154
А.4. Управление Изменениями. 154
А.6. Управление Доступностью.. 155
А.7. Управление Мощностями. 155
А.8. Управление Непрерывностью ИТ-сервиса. 155
А.9. Управление Финансами. 156
А.10. Управление Уровнем Услуг. 156
Глава 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), обсуждаются вопросы планирования корпоративной культуры и Управления Персоналом, а также координация бизнес-процессов компании с работой ИТ-служб. - Управление Процессами: в данном разделе рассматриваются вопросы Управления Процессами ИТ Сервис-менеджмента. Часто организации в значительной степени зависят от ИТ-услуг. Они ожидают, что ИТ-услуги будут не только поддержкой организации, но и дадут новые возможности для реализации целей бизнеса. Более того, ожидания заказчика могут существенно меняться со временем. Провайдеры ИТ-услуг также не могут себе позволить концентрироваться только на технологических аспектах и своих внутренних организационных вопросах. В настоящее время они должны задумываться над качеством предоставляемых услуг и взаимоотношениями со своими заказчиками. Предоставление ИТ-услуг охватывает все вопросы менеджмента ИТ-инфраструктуры, включая обслуживание и сопровождение. Перед покупкой любого продукта в магазине, мы обычно оцениваем его качество по внешнему виду, пригодности и надежности. В магазине у покупателя немного возможностей повлиять на качество продукта из-за того, что он уже произведен на фабрике. Путем тщательного контроля производства изготовитель будет стараться поставлять продукция с одинаковым Уровнем Качества. В этом примере изготовление, продажа и потребление выступают отдельными друг от друга этапами. Услуги предоставляются при непосредственном взаимодействии с заказчиком. Качество услуги нельзя оценит заранее, это делается только при ее предоставлении. Качество в определенной степени зависит от того, как поставщик взаимодействует с заказчиком. В отличие от процесса производства, услугу можно изменить на этапе ее предоставления заказчику. Как заказчик воспринимает услугу, и что думает поставщик о том, что он поставляет – все в значительной степени зависит от их личных опыта и ожиданий. Процесс предоставления услуги - это сочетание производства и потребления, в котором поставщик и заказчик участвуют одновременно. Восприятие заказчика является существенным фактором при предоставлении услуг. Обычно заказчики задают себе следующие вопросы при оценке качества услуги: - Отвечает ли услуга связанным с ней ожиданиями- - Могу ли я ожидать получение такой же услуги в следующий раз- - Предоставлена ли услуга по разумной цене- Насколько услуга отвечает ожиданиям, в большей степени зависит от того, насколько хороши были предварительно согласованы параметры сервиса во время диалога с заказчиком, чем от самого предоставления услуги. Непрерывный диалог с заказчиком является необходимым условием для усовершенствования услуги и для того, чтобы и заказчик, и поставщик знали, чего стоит ожидать. В ресторане официант вначале расскажет о меню и при подаче нового блюда поинтересуется, все ли нормально. Официант активно координирует спрос и предложение на протяжении всего времени посещения ресторана клиентом, а затем использует полученный опыт для улучшения обслуживания других посетителей. Качество услуги – это показатель того, насколько услуга отвечает требованиям и ожиданиям заказчика. Для обеспечения качества поставщик должен постоянно оценивать, как услуга воспринимается заказчиком, и что клиент ожидает получить в будущем. Что для одного заказчика является обычным, для другого будет чем-то особенным. И в конечном итоге заказчик может привыкнуть к тому, что в самом начале считалось особенным. Результаты оценки можно использовать для определения того, нужно ли модифицировать услугу, предоставлять ли заказчику больше информации о ней или стоит изменить ее цену. Качество – это совокупность характеристик продукта или услуги, которые формируют способность продукта удовлетворять сформулированные и подразумеваемые потребности (ISO-8402). Понятие "разумная цена" можно рассматривать как производное понятие. После того, как достигнуто Соглашение об Ожиданиях Заказчика, можно обсудить цену. На данном этапе поставщик должен знать, каковы его затраты на сервисы и какие существуют текущие рыночные расценки на аналогичные услуги. Заказчик будет недоволен тем поставщиком, который иногда работает свыше ожиданий, но разочаровывает в другой раз. Обеспечение постоянного качества является одним из наиболее важных, но и наиболее трудных аспектов индустрии услуг. Например, ресторан должен закупать свежие продуты, поварам нужно работать вместе для достижения хорошего общего результата, и обслуживающий персонал, по возможности, должен иметь одинаковый профессиональный уровень. Ресторану будет присвоено только три звезды, если высокое качество обслуживания будет непостоянным. Ситуация не всегда бывает такой стабильной: обслуживающий персонал может быть разным по своей профессиональной подготовке, хорошее мнение на рынке может поменяться, повара могут уйти и открыть свои рестораны. Обеспечение стабильно высокого качества предполагает скоординированную работу всех элементов: чем лучше и быстрее работает кухня, тем быстрее обслуживаются посетители. Таким образом, при предоставлении услуг общее качество обслуживания складывается из качества составляющих процессов, которые вместе образуют услугу. Такие составляющие процессы формируют цепочку, звенья которой влияют одно на другое и на качество услуги в целом. Для эффективной координации составляющих процессов требуется не только адекватное качество при выполнении каждого процесса, но еще и качество согласования процессов между собой. Поставка продуктов от услуг требует работы, то есть совершения определенных действий. Качество продукции или услуги во многом зависит от того, как организована работа. Цикл качества Деминга (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ности организации извлекать уроки из полученного опыта и реализовывать на практике непрерывный процесс улучшения качества. Опыт работ по улучшению качества ИТ-услуг показал, что недостаточно заниматься только структурированием существующей практики. Причины несоответствия предоставляемых услуг требованиям заказчика часто кроются в способе Управления ИТ-организацией. Для постоянного совершенствования качества требуется определенная степень зрелости организации. Для определения зрелости организации можно использовать модель, разработанную Европейским фондом Управления Качеством (EFQM — European Foundation for Quality Management) (рис. 2.2). С помощью данной модели определяются основные сферы деятельности, которые следует принимать во внимание при Управлении Организацией. Цикл качества Деминга входит составной частью в модель EFQM. Действия (определение стратегии, курса движения организации) предпринимаются на основе результатов, полученных в тех областях, которые предполагают их получение. Такие действия являются фундаментом планирования (например, структуры процессов), целью которого является достижение желаемых результатов. Модель EFQM определяет девять сфер деятельности.
Рис. 2.2. Модель EFQM Голландская организация по вопросам качества (INK) дополнительно поделила модель EFQM на этапы, давая тем самым возможность определить, в какой степени компании удалось реализовать общее Управление Качеством в отдельной области и в организации в целом. Определено пять этапов:
- Нацеленность на продукт - этап, известный как ориентированный на результат; все в организации работают напряженно (но в этих усилиях отсутствует направленность); деятельность организуется специальным образом для каждого конкретного случая[6]
. - Нацеленность на процесс – этап также известен под названием "мы знаем, что делаем"; деятельность организации имеет плановый и повторяющийся характер. - Нацеленность на систему – или "сотрудничество подразделений". - Нацеленность на цепочку[7]
- этап также известен под названием "внешнее партнерство"; организация концентрирует усилия на том качестве, которое она добавляет как составляющий элемент к цепочке поставщик-заказчик. - Нацеленность на всеобщее качество[8]
- этап, называемый "рай на земле"; организация достигла такого уровня, когда постоянное и сбалансированное стремление к совершенствованию стало нормой. Сферы деятельности, определенные с помощью модели EFQM, можно увязывать с показателями организационной зрелости. Уровень Зрелости организации в каждой из этих областей определяется с помощью анкетирования. Такую оценку могут провести собственные или приглашенные аудиторы. После определения Уровня Зрелости организация может приступать к разработке стратегии совершенствования, которая в дальнейшем будет преобразована в работы. План, который составляется с учетом модели на один год, определяет, какие аспекты в каждой сфере деятельности нужно улучшить и как это сделать. Путем повторения процесса самооценки и планирования организация сможет контролировать Уровень своей Зрелости. Основные преимущества данного подхода следующие; руководство организации может вести ее по выбранному стратегическому курсу. В дополнение к подходу EFQM существует много других видов самооценки и проверки организационной зрелости. Некоторые из них сфокусированы в основном на внутренней структуре организации. Следует помнить, что совершенствование отдельных элементов внутренней структуры организации может лишь частично повлиять на общие результаты компании в тех случаях, когда не совершенствуются отношения с заказчиками, персонал не получает удовлетворения от работы, не улучшается руководство организацией или же когда стратегия и тактика организации четко не определены. В ИТ индустрии процесс развития Уровня Зрелости наиболее известен через Модель зрелости (Capability Maturity Model – СММ). Эта модель была создана в институте разработки программного обеспечения (ПО) (Software Engineering Institute – SEI) в университете Карнеги-Меллона (Carnegie Mellon). Она предназначается для совершенствования процессов разработки ПО и повышения степени зрелости этих процессов. Модель СММ включает в себя следующие уровни: - Начальный уровень – процессы выполняются индивидуально для каждого конкретного случая[9]
. - Уровень Повторяющихся Процессов – процессы становятся повторяющимися и организованы таким образом, чтобы качество услуг стало повторяющимся. - Уровень Документированных Процессов – процессы в организации документированы, стандартизованы и интегрированы. - Уровень Управляемых Процессов – организация оценивает полученные результаты и использует их для повышения качества предоставляемых услуг. - Уровень Оптимизирующихся Процессов – организация постоянно оптимизирует свои процессы с целью повышения качества услуг или разработки новой технологии или сервисов. На основе вышеперечисленных Уровней Зрелости процессов были разработаны модели ИТ Сервис-менеджмента. Разрабатывая и сопровождая системы качества, отвечающие требованиям стандарта серии ISO-9000 (ISO-9000-2000),
организация может достичь Уровня "Нацеленности на систему" (или Уровня "Управляемых процессов" по терминологии модели СММ). Эти стандарты ISO уделяют основное внимание определению, описанию и проектированию процессов.
Рис. 2.3. Связи заказчик-поставщик и Уровни Зрелости При оценке зрелости организации нельзя ограничиться только поставщиком услуг. Здесь также важен Уровень Зрелости Заказчика (рис. 2.3). Если разница в степени зрелости компаний заказчика и поставщика велика, то ее следует учитывать, если нет желания столкнуться с несоответствием подходов и стилей работы в этих компаниях. Особенно это относится к организации взаимодействия между заказчиком и поставщиком. Целесообразно, чтобы компании заказчика и поставщика выходили на одинаковый Уровень Организационной Зрелости, и взаимодействие происходило бы на этом Уровне или было скорректировано с учетом более низкого уровня одного из партнеров. 2.2. Организация и ее политика (правила работы)
[10]
В предыдущих разделах была проиллюстрирована тесная взаимосвязь качества услуг и качества работы самой организации с ее политикой (правилами работы). В данном разделе будут рассмотрены некоторые важные аспекты работы организации и ее политики, имеющие отношение к вопросу Управления Процессами. Организация – это определенная форма сотрудничества людей. Перед любой организацией, будь это дартс-клуб или мультинациональная компания, стоит вопрос: в чем цель объединения в организацию- Такой корпоративной целью (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. Горизонты планирования У технической инфраструктуры самый дальний горизонт (период) планирования. Она выполняет поддерживающую роль и ее связи с реальной бизнес-деятельностью видны не всегда четко. На разработку инфраструктуры требуется время. Кроме того, зависимость информационных систем и бизнеса от технической инфраструктуры вносит ограничения на проведение ее изменений. Более того, разработка и создание инфраструктуры требует значительных инвестиций, и поэтому следует учитывать период ее амортизации. У приложений горизонт планирования ближе, так как они разрабатываются для выполнения конкретной бизнес-задачи. Планирование жизненного цикла приложения в первую очередь основывается на тех бизнес-функциях, которые должна будет выполнять система, после чего принимаются на рассмотрение технологии, которые могут использоваться для достижения поставленных целей. Бизнес-планы, составленные на основе стратегии организации, обычно рассчитаны на один календарный или финансовый год. Составление бюджета, планирование, составление отчетов о ходе выполнения работ осуществляется, исходя из этого периода. На некоторых рынках время, отводимое на планирование, еще больше сокращается, как и время для разработки продукта. В планах должны быть отражены четыре аспекта: - Время – самый легкий для определения показатель. Время определяется датой начала и окончания работ, и очень часто разбивается на этапы. - Количество – цели должны поддаваться измерению для осуществления мониторинга хода выполнения. Такие определения целей, как "улучшенный" или "более быстрый", недостаточны для планирования. - Качество – качество результата должно соответствовать поставленной цели. - Затраты и доходы – результаты работы должны быть соразмерны предполагаемым затратам, усилиям и полученным доходам. Различие в горизонтах планирования наблюдается не только между разными сферами деятельности, но и между разными Уровнями Процессов (стратегическим, тактическим и операционным). Более подробно этот вопрос будет рассматриваться в последующих главах. Организации, производящие изменения, например, ради повышения качества предоставляемых услуг, в конечном итоге столкнутся с вопросами корпоративной культуры, существующей у них в настоящий момент. Под корпоративной (организационной) культурой понимается то, как люди общаются друг с другом в организации, как принимаются и выполняются решения, как сотрудники относятся к работе, заказчикам, поставщикам, руководству и коллегам. Культуру, которая зависит от норм поведения и ценностей, принятых в организации, нельзя контролировать, но на нее можно влиять. Для оказания такого влияния от руководства требуется демонстрация лидерства, проведение четкой и последовательной политики и поддержка со стороны персонала. Корпоративная культура может оказать существенное воздействие на оказание ИТ-услуг. Бизнес может относиться к инновациям по-разному. Существуют организации со сложившейся стабильной корпоративной культурой, в которых на инновации не обращают большого внимания. У такой организации могут возникнуть трудности с приведением ИТ-услуг в соответствие с изменениями в организации. С другой стороны, если структура ИТ-подразделения нестабильна и подвержена частым изменениям, то такая корпоративная культура может стать серьезной помехой на пути обеспечения качества услуг. В этом случае может возникнуть ситуация, когда большое количество бесконтрольных изменений приведет к появлению многочисленных сбоев в работе. Политика Управления Персоналом играет важную стратегическую роль в достижении организацией долгосрочных целей (также см. модель EFQM). Она также может быть использована в качестве инструмента изменения корпоративной культуры. Цель современного подхода к Управлению Персоналом – оптимизация производительности работы всего персонала организации. Для этого используются такие средства, как подбор кадров, обучение и продвижение по службе, мотивация труда и вознаграждение (поощрение). Концепция HRM является основной формой современного Управления Персоналом. Концепция HRM основывается на двух предпосылках: - Управление Персоналом должно способствовать достижению стратегических целей организации. Если организация должна реагировать лучше и быстрее на еще более быстрые изменения в своем окружении, то это должно найти отражение в подборе и расстановке кадров, качестве и численности персонала. - Создание работникам организации условий для применения и развития своих способностей и навыков послужит на пользу организации. Существует три подхода к Управлению Персоналом: - Жесткий подход – в этом случае людские ресурсы рассматриваются как средство производства. Они должны быть организованы наиболее эффективным и рациональным способом (effectively and efficiently). Как и корпоративная стратегия, политика управления персоналом определяется экономическими, техническими и рыночными условиями. При таком подходе значимость работников оценивается по-разному. Некоторые ключевые специалисты стратегически являются более важными, чем другие, вспомогательные работники, которым можно легко найти замену. Например, при таком подходе компания может принять решение, что только ключевые специалисты будут работать на постоянной основе, а все остальные – на контрактной. - Мягкий подход – в этом случае основной акцент делается на наилучшее использование потенциала сотрудников во благо компании. Современные специалисты высокообразованны, честолюбивы и готовы многое отдавать работе. Именно поэтому следует как можно раньше определить их потенциал и постоянно развивать его (обучение, создание условий для профессионального роста). При определении своей стратегии и политики организация должна опираться на таланты и потенциальные возможности всех своих сотрудников. - Интегрированный подход – такой подход строится на общих интересах персонала и руководства организации. Для достижения целей в организации должен быть нормальный приток, движение и отток кадров. Изменения на рынке и в организации (например, изменение в технологических областях) ведут к постоянным изменениям в спросе на различные специальности. Все аспекты политики Управления Персоналом должны быть тщательно скоординированы. Перемещение работников в организации, определение и развитие их навыков (компетенции) и содействие мобильности внутреннего рынка труда становятся все более важными для организации. Качество предоставляемых услуг только выиграет от наиболее полного раскрытия потенциала работников организации. Это способствует непрерывному совершенствованию организации. Инструментами улучшения Управления Персоналом являются: - Доведение политики организации до ее сотрудников – объяснение каждому сотруднику, в какой степени его работа способствует достижению целей, стоящих перед организацией. Важным условием успеха в этом направлении является участие в нем всех уровней руководства. - Оказание доверия, предоставление полномочий[18]
– сотрудники получают возможность организовывать и выполнять свою работу по согласованию с организацией. Объем предоставляемых полномочий определяет Уровень Ответственности, которую сотрудники несут за качество выполненной работы. - Ответственность[19]
– результат применения двух первых пунктов. Если сотрудникам объяснили, чего от них ожидают, и если они имели возможность организовывать и выполнять свою работу так, как они считали нужным, то они несут полную ответственность за свою работу. Это может служить основой для оценки и вознаграждения сотрудников. Это вознаграждение может быть как материальным, так и нематериальным, например, признание или новые возможности для профессионального роста и развития карьеры и т. д. - Управление Уровнем Компетенции[20]
– является одновременно как средством наиболее эффективного применения уже имеющихся в распоряжении организации знаний, так и способом систематического развития знаний, необходимых для компании. Данный подход позволяет определять, какой Уровень Компетенции требуется для выполнения необходимых процессов или проектов, а так же каким Уровнем Знаний должны обладать сотрудники. При организации работы персонала компания фокусируется не только на достижении нужного баланса между требуемым и существующим Уровнем Компетенции сотрудников, но и на создании условий для развития компетенции, обмена знаниями и обучения новым навыкам. В этом сотрудникам могут помочь наставники[21]
. Формирование коллективов сотрудников по областям знаний (по их специализации) способствует обмену опытом и появлению новых областей компетенции. Качество ИТ-услуг во многом зависит от взаимоотношений с заказчиками. На основе этих отношений разрабатываются и корректируются Соглашения. Сферой действия Управления Отношениями с Заказчиками ИТ-услуг (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.7 постоянно возникают при использовании процессного подхода, типичного для современного ИТ Сервис-менеджмента. Средства для нахождения ответов на них приведены в правой части рисунка.
Рисунок 2.7. Модель совершенствования процессов При организации работ в виде процессов не учитываются ни существующее распределение работ, ни деление организации на отделы. Это сознательный выбор. Делая выбор в пользу процессной структуры, можно доказать, что некоторые виды работ в организации не координируются, дублируют друг друга, игнорируются или вообще не нужны. Процесс – это логически взаимосвязанная между собой последовательность работ (видов деятельности[26]
), направленная на достижение поставленной цели. Вместо этого мы сосредотачиваемся на цели процесса и его взаимоотношениях с другими процессами. Процесс – это последовательность работ, нацеленная на преобразование входных данных (информации, документации и т. д.) в выходные. Для получения информации о том, каким будет результат выполнения процесса, нужно проверить вход и выход каждого процесса на соответствие характеристикам качества и стандартам. В результате этого получаются цепочки процессов, по которым можно отследить, что происходит в организации и какой результат получается, а также определить контрольные точки в этих цепочках, в которых выполняется мониторинг качества продуктов и услуг, предоставляемых организацией. Стандарты для выходных данных каждого процесса должны быть определены таким образом, чтобы вся цепочка процессов обеспечивала достижение корпоративных стратегических целей. Если результат процесса отвечает заданному стандарту, такой процесс будет считаться эффективным (effective). Если работы в рамках данного процесса к тому же выполняются с наименьшими усилиями и затратами, этот процесс будет рациональным (efficient)[27]
. Цель Управления Процессами — планировать и контролировать процессы таким образом, чтобы они были одновременно эффективными и рациональными. Для оптимизации качества процессов каждый из них можно рассматривать отдельно. Владелец процесса несет ответственность за результаты работы процесса. Менеджер процесса отвечает за его структуру и выполнение и подотчетен владельцу процесса[28]
. Координаторы процесса отвечают за выполнение заданных видов работ и отчитываются о результатах их выполнения менеджеру процесса.
Рис. 2.8. Общая диаграмма процесса Логическая структуризация работ внутри процесса позволяет установить четкие точки перехода, в которых есть возможность выполнять мониторинг качества процесса. В примере с рестораном мы можем разделить обязанности по закупке продуктов и приготовлению блюд так, чтобы повара не занимались закупками, и, возможно, не тратили слишком много времени на оценку свежести ингредиентов, которая не влияет на их работу. Руководство организации может осуществлять контроль, основываясь на информации о качестве каждого из процессов. В большинстве случаев соответствующие показатели эффективности[29]
и стандарты уже будут предопределены Соглашениями. Поэтому каждодневный контроль процесса передается Руководителю (менеджеру) Процесса. Владелец процесса будет оценивать работу по показателям производительности и их соответствию согласованному стандарту. Без четких показателей владельцу процесса будет трудно определить степень контролируемости процесса и реализации запланированных улучшений. Часто процессы описывают с помощью процедур и рабочих инструкций. Процедура – это описание логически связанных видов работ с указанием их исполнителей. Процедура может включать в себя этапы из различных процессов. Процедура определяет, что должно выполняться и кем, и она может меняться в зависимости от организации. Набор Рабочих инструкций определяет, как следует выполнять виды работ, входящих в состав процедур. На рис. 2.9 представлена модель процесса, созданная с использованием подхода ITIL. Эта модель является основой процессов ИТ Сервис-менеджмента, описанных в этой книге.
Рис. 2.9. Обобщенная модель процессов ITIL Большинство компаний имеют иерархическую структуру. Они состоят из подразделений, объединяющих группы сотрудников. Существуют разные принципы формирования подразделений, например, по типу заказчика, продукту, региону или области знания. Как правило, в предоставлении ИТ-услуг (сервисов) участвуют одновременно несколько отделов и затрагиваются несколько областей знаний. Например, если существует ИТ-сервис по предоставлению доступа к программе бухгалтерского учета на центральном компьютере, то в это будет вовлечено несколько подразделений. Вычислительный центр должен будет обеспечить доступ к программе и базе данных, служба передачи данных и телекоммуникаций будет обеспечивать связь с вычислительным центром, а подразделение поддержки персональных компьютеров - предоставлять пользователям интерфейс для доступа к программе.
В процессах, в которых участвует несколько подразделений, контроль качества услуг осуществляется путем мониторинга определенных аспектов качества, например таких, как доступность, мощность[30]
ИТ-средств (пропускная способность), стоимость и стабильность. Затем ИТ-организация сопоставляет результаты мониторинга качества с потребностями заказчика. Структура таких процессов гарантирует получение качественной информации о предоставлении услуг, так, чтобы можно было совершенствовать контроль и планирование услуг. ИТ Сервис-менеджмент в первую очередь известен как ориентированный на процессы и услуги подход, который использовался в области, ранее известной как ИТ-менеджмент. В этой главе показано, что у процессов всегда должна быть определена цель. В свою очередь, цель процессов ИТ Сервис-менеджмента – содействовать повышению качества ИТ-услуг. Управление Качеством и контроль процессов являются частью организации и ее политики. При процессно-ориентированном подходе необходимо учитывать ситуацию внутри организации (внутреннюю политику, корпоративную культуру, численность и так далее). ITIL, наиболее известный подход к ИТ Сервис-менеджменту, не дает каких-либо ограничений по типу организации, а, наоборот, описывает связи между видами деятельности, составляющими процессы, которые применимы в организациях любого типа. Это создает структурированную основу[31]
для обмена опытом между компаниями и изучения опыта динамично развивающихся организаций. В данной главе описывается структура и задачи библиотеки передового опыта организации ИТ (ITIL)[32]
и приводятся сведения об организациях, способствующих превращению ITIL в лучший практический стандарт для ИТ Сервис-менеджмента. Библиотека 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 развивалась с целью достижения преимуществ для ИТ-организации и компании в целом. Многие из лучших практических предложений направлены на предотвращение таких проблем или их решение в случае возникновения. Библиотека ITIL первоначально была результатом работы Центрального агентства по вычислительной технике и телекоммуникациям (Central Computer and Telecommunications Agency – CCTA) при правительстве Великобритании. В апреле 2001 г. ССТА было объединено с Государственной торговой палатой (Office of Government Commerce – OGC), являющейся в настоящее время новым влаельцем библиотеки ITIL Целью OGC является помощь заказчикам из государственного сектора экономики Великобритании в модернизации их деятельности по закупкам и улучшении обслуживания путем максимального использования ИТ и других инструментариев. "Задачей OGC является модернизация закупок правительственными службами и работа по улучшению использования финансовых средств"[38]
. OGC способствует использованию "передового опыта"[39]
в различных сферах деятельности (например, Управление Проектами, Управление Закупками и ИТ Сервис-менеджмент). OGC выпускает несколько книжных серий (библиотек), написанных экспертами из Великобритании и других стран мира, представляющими ряд компаний и организаций. Принадлежащая OGC библиотека ITIL состоит из ряда доступных и детальных "Собраний практических руководств"[40]
для предоставления эффективных и рациональных[41]
ИТ-услуг (сервисов). Форум по ИТ Сервис-менеджменту (Information Technology Service Management Forum – itSMF), ранее известный как Форум по менеджменту ИТ-инфраструктуры (Information Technology Infrastructure Management Forum – ITIMF) является единственной имеющей международное признание независимой группой пользователей[42]
, занимающейся вопросами ИТ Сервис-менеджмента. Ее единственными владельцами и управляющими являются члены группы. Форум itSMF оказывает определяющее влияние и делает вклад в популяризацию передового опыта и разработку стандартов во всем мире. Первая региональная организация itSMF возникла в Великобритании в 1991 г. Следующей была голландская (itSMF — The Netherlands), учрежденная в Нидерландах в 1993 г. Сейчас отделения форума itSMF есть в таких странах, как ЮАР, Бельгия, Германия, Австрия, Швейцария, Канада, США и Австралия; все они сотрудничают в рамках форума itSMF International. Сайты этих отделений указаны в приложении В2. Региональные отделения itSMF способствуют обмену информацией и опытом, что позволяет ИТ-организациям повысить качество поставляемых услуг. Они организуют семинары, конференции, обсуждения отдельных тем и другие мероприятия, посвященные современным проблемам ИТ Сервис-менеджмента. Кроме того, они издают информационные бюллетени и используют Web-сайты для обмена информацией. Рабочие группы[43]
способствуют дальнейшему развитию библиотеки ITIL. Голландская организация "Exameninstituut voor Informatica" (EXIN) и британская "Information Systems Examination Board" (ISEB) совместно разработали профессиональную систему сертификации в рамках библиотеки ITIL. Разработка проводилась в тесном сотрудничестве с OGC и itSMF. EXIN и ISEB являются некоммерческими организациями, сотрудничающими для разработки всего диапазона квалификационных сертификатов ITIL трех уровней: - базовый сертификат по ИТ Сервис-менеджменту – Foundation Certificate in IT Service Management, - сертификат специалиста по ИТ Сервис-менеджменту – Practitioner Certificate in IT Service Management; - сертификат менеджера по ИТ Сервис-менеджменту – 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]
, базирующуюся на практическом опыте профессиональных пользователей по всему миру. Каждая из книг библиотеки 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 Infrastructure 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. Как уже отмечалось, Поддержка услуг и Предоставление услуг считаются центральными компонентами передового опыта ITIL для ИТ Сервис-менеджмента. В книге ITIL по Предоставлению услуг описываются требования, необходимые для оказания услуг. В этой серии рассматриваются следующие вопросы: - Управление Уровнем Услуг; - Управление Финансами ИТ; - Управление Мощностями; - Управление Непрерывностью ИТ-услуг; - Управление Доступностью. В данную ознакомительную книгу было включено также Управление Информационной Безопасностью (со ссылкой на книгу ITIL по информационной безопасности), но оно не является частью серии по предоставлению услуг. Сложную взаимосвязь между процессами, описываемыми в книгах по Поддержке и Предоставлению услуг, почти невозможно отразить графически. В общих чертах они показаны в виде упрощенной схемы на рис. 3.3.
Рис. 3.3. Поддержка и Предоставление Услуг. Управление Уровнем Услуг
Целью Управления Уровнем Услуг является достижение ясных соглашений с заказчиком об ИТ-услугах и реализация этих соглашений. Соответственно, для Управления Уровнем Услуг необходима информация о потребностях заказчика, о предоставляемых ИТ-организацией технических средствах и о имеющихся финансовых ресурсах. Управление Уровнем Услуг рассматривает услуги, предоставляемые заказчику (с акцентом на заказчике[49]
). ИТ-организация может повысить степень удовлетворенности заказчика через создание услуг за основе его потребностей (услуги, вызванные спросом[50]
), только на базе своих технических возможностей (услуги, вызванные предложением[51]
). В главе об Управлении Уровнем Услуг книги по Предоставлению услуг рассматриваются следующие вопросы: - как оптимизировать ИТ-услуги для их предоставления заказчикам по доступным ценам на основе точного определения договоренностей в Соглашении об Уровне Услуг; - как проводить мониторинг и обсуждение услуг; - как организовать Поддержку Услуг Внешними Договорами[52]
с поставщиками. Управление Финансами ИТ
Управление Финансами касается экономических вопросов предоставляемых ИТ-услуг. Например, Процесс Управления Финансами подготавливает информацию о расходах, возникших при предоставлении услуг. В результате при определении необходимых изменений ИТ-инфраструктуры или ИТ-услуг возможен учет финансовых факторов (соотнесение расходов и доходов – цены и результата). Определение, отнесение расходов, их прогноз и отслеживание, рассматривавшиеся в главе об управлении финансами книги по предоставлению услуг, - все это охватывается термином "расчет себестоимости"[53]
, а в нынешнем издании ITIL называется "бюджетированием и бухгалтерским учетом". Эта деятельность повышает информированность о расходах (где возникают издержки и какие) и может использоваться также при составлении бюджета. Управление Финансами ИТ описывает различные методы выставления счетов, включая определение цели выставления счетов за ИТ-услуги (для чего это используется в компании-) и определение ценообразования, а также аспекты бюджетирования. Управление Мощностями
Управление Мощностями представляет собой процесс оптимизации расходов, времени приобретения и размещения ИТ-ресурсов с целью обеспечения выполнения договоренностей с заказчиком. Процесс Управления Мощностями имеет дело с Управлением Ресурсами, Управлением Производительностью, Управлением Спросом на ИТ, моделированием, планированием мощностей, Управлением Нагрузкой и определением необходимого объема технических средств для работы приложений[54]
. В Управлении Мощностями акцент делается на планировании для обеспечения согласованного Уровня Услуг сейчас и в будущем. Управление Доступностью
Управление Доступностью является процессом, обеспечивающим соответствующее размещение ресурсов, методов и технологий для поддержки Уровня Доступности ИТ-услуг, согласованных с заказчиком. Управление Доступностью занимается такими вопросами, как оптимизация обслуживания и разрабатывает способы минимизации числа инцидентов. Управление Непрерывностью ИТ-услуг
Этот процесс касается подготовки и планирования способов устранения чрезвычайных ситуаций с ИТ-услугами в случае остановки бизнеса. Называвшийся в предыдущем издании ITIL "Планированием на случай чрезвычайных обстоятельств"[55]
, этот процесс уделяет основное внимание связям между всеми компонентами, необходимым для защиты непрерывности деятельности компании при катастрофах (т. е. для Управления Непрерывностью Бизнеса), а также средствам предотвращения таких катастроф. Управление Непрерывностью ИТ-услуг является процессом планирования и координации технических, финансовых и управленческих ресурсов, необходимых для обеспечения непрерывности услуг после катастроф, в соответствии с договоренностью с заказчиком. В книге 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 Управление Инцидентами
Задача Процесса Управления Инцидентами является реактивной – уменьшение или исключение отрицательного воздействия (потенциальных) нарушений в предоставлении ИТ-услуг, таким образом обеспечивая наиболее быстрое восстановление работы пользователей. Для выполнения этой задачи производится регистрация, классификация и назначение инцидентов соответствующим группам специалистов, мониторинг хода работ по разрешению инцидентов, решение инцидентов и их закрытие. Так как это требует тесного взаимодействия с пользователями, фокусной точной Процесса управления Инцидентами обычно является функция Service Desk[58]
, которая играет роль центра контактов пользователей с "внутренними" коллективами технических служб. Управление Инцидентами является важнейшей основой для работы других процессов ITIL, предоставляя ценную информацию об ошибках в работе ИТ-инфраструктуры. На рис. 4.1 показан схематичный пример Управления Инцидентами как горизонтальный процесс, охватывающий разные ИТ-отделы и осуществляющий эффективное управление и контроль обработки инцидентов.
Рис. 4.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) Целью Процесса Управления Инцидентами является скорейшее восстановление нормального Уровня Услуг, определенного в Соглашении об Уровне Услуг (Service Level Agreement – SLA), с минимальными возможными потерями для бизнес-деятельности организации и пользователей. Кроме того, Процесс Управления Инцидентами должен вести точную регистрацию инцидентов для оценки и совершенствования процесса и предоставления необходимой информации для других процессов. - Для бизнеса в целом: - своевременное разрешение инцидентов, ведущее к уменьшению потерь для бизнеса; - повышение производительности работы пользователей; - независимый, ориентированный на потребности заказчика мониторинг инцидентов; - доступность объективной информации о соответствии предоставляемых услуг согласованным договоренностям (SLA). - Для ИТ-организации: - улучшенный мониторинг, позволяющий проводить точное сопоставление уровня производительности ИТ-систем с соглашениями (SLA); - эффективное руководство и мониторинг выполнения соглашений (SLA) на основе достоверной информации; - эффективное использование персонала; - предотвращение потерь инцидентов и Запросов на Обслуживание или их неправильной регистрации; - повышение точности информации в Конфигурационной Базе Данных (Configuration Management Database – CMDB) за счет ее проверки при регистрации инцидентов в привязке к Конфигурационным Единицам (Configuration Item – CI); - повышение удовлетворенности пользователей и заказчиков. Отказ от использования Процесса Управления Инцидентами может привести к следующим отрицательным последствиям: - инциденты могут быть потеряны или, наоборот, необоснованно восприняты как чрезвычайно серьезные из-за отсутствия ответственных за мониторинг и эскалацию, что может привести к снижению общего уровня обслуживания; - пользователи могут перенаправляться к одним и тем же специалистам "по кругу" без успешного разрешения инцидента; - специалисты могут постоянно отрываться от работы телефонными звонками пользователей, из-за чего им становится трудно эффективно выполнять свою работу; - могут возникать ситуации, когда несколько человек будут работать над одним и тем же инцидентом, непродуктивно теряя время, и примут противоречивые решения; - может ощущаться недостаток информации о пользователях и предоставляемых услугах, необходимой для принятия руководящих решений; - из-за указанных выше возможных проблем затраты компании и ИТ-организации на поддержку услуг будут выше, чем реально требуется. 4.3. Процесс
На рис. 4.4 показаны входы и выходы процесса, а также виды деятельности, которые охватывает этот процесс.
Рис. 4.4. Положение Процесса Управления Инцидентами Инциденты могут возникнуть в любой части инфраструктуры. Часто о них сообщают пользователи, но возможно их обнаружение и сотрудниками других отделов, а также автоматическими системами управления, настроенными на регистрацию событий в приложениях и технической инфраструктуре. Конфигурационная База Данных (Configuration Management Database - CMDB) играет важную роль в Управлении Инцидентами, так как она определяет связь между ресурсами, услугами, пользователями и Уровнями Услуг (сервисов). Например, Управление Конфигурациями показывает, кто является ответственным за компонент инфраструктуры, что делает возможным более эффективное распределение инцидентов по группам специалистов. Кроме того, эта база данных помогает решать оперативные вопросы, например, перенаправление очереди печати или переключение пользователя на другой сервер. При регистрации инцидента в регистрационные данные добавляется связь (link) с соответствующей Конфигурационной Единицей (Configuration Item – CI), позволяющая предоставить более подробную информацию об источнике ошибки. В случае необходимости может быть обновлен статус соответствующей компоненты в CMDB. Эффективное Управление Проблемами требует качественной регистрации инцидентов, что значительно облегчит поиск корневых причин. С другой стороны, Управление Проблемами помогает Процессу Управления Инцидентами, предоставляя информацию о проблемах, известных ошибках, обходных решениях и быстрых исправлениях[66]
. Инциденты могут быть решены путем внесения изменений, например, заменой монитора. Управление Изменениями предоставляет Процессу Управления Инцидентами информацию о запланированных изменениях и их статусах. Кроме того, изменения могут вызвать инциденты, если изменения произведены неправильно или содержат ошибки. Процесс Управления Изменениями получает информацию о них из Процесса Управления Инцидентами. Управление Уровнем Услуг контролирует выполнение договоренностей (соглашений – SLA) с заказчиком о предоставляемой ему поддержке. Сотрудники, участвующие в Управлении Инцидентами должны хорошо знать эти соглашения, чтобы использовать необходимую информацию при контактах с пользователями. Кроме того, регистрационные данные об инцидентах требуются при составлении отчетов для проверки выполнения согласованного Уровня Услуг. Для определения показателей доступности услуг Процесс Управления Доступностью использует регистрационные данные об инцидентах и данные мониторинга статуса, предоставляемые Процессом Управления Конфигурациями. Аналогично Конфигурационной Единице (CI) в Конфигурационной Базе Данных (CMDB), сервису (услуге) может быть также назначен статус "не работает"[67]
. Это может быть использовано для проверки действительных показателей доступности услуги и времени реагирования поставщика. При осуществлении такой проверки необходима фиксация времени действий, произошедших в процессе обработки инцидента, от момента обнаружения и до закрытия. Процесс Управления Мощностями получает информацию об инцидентах, связанных с функционированием самих ИТ-систем, например, инцидентах, произошедших в связи с недостатком дискового пространства или медленной скоростью реакции и т.д. В свою очередь, информация об этих инцидентах может поступать в Процесс Управления Инцидентами от системного администратора или от самой системы на основе мониторинга своего состояния. Ни рис. 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) – весь цикл обработки инцидента контролируется, и если инцидент не может быть разрешен вовремя, производится эскалация. В большинстве случаев инциденты регистрируются Службой Service Desk, куда поступают сообщения о них. Регистрация всех инцидентов должна производиться немедленно после поступления сообщения по следующим причинам: - трудно произвести точную регистрацию информации об инциденте, если это не сделано сразу; - мониторинг хода работ по решению инцидента возможен, только если инцидент зарегистрирован; - зарегистрированные инциденты помогают при диагностике новых инцидентов; - Управление Проблемами может использовать зарегистрированные инциденты при работе над поиском корневых причин; - легче определить степень воздействия, если все сообщения (звонки) зарегистрированы; - без регистрации инцидентов невозможно контролировать исполнение договоренностей (SLA); - немедленная регистрация инцидентов предотвращает ситуации, когда или несколько человек работают над одним звонком, или никто ничего не делает для разрешения инцидента. Место обнаружения инцидента определяется по признаку, откуда пришло сообщение о нем. Инциденты могут быть обнаружены следующим образом: - Обнаружен пользователем: он докладывает об инциденте в Службу Service Desk. - Обнаружен системой: при обнаружении события в приложении или технической инфраструктуре, например, при превышении критического порога, событие регистрируется как инцидент в системе регистрации инцидентов и, при необходимости, направляется в группу поддержки. - Обнаружен сотрудником Службы Service Desk: сотрудник производит регистрацию инцидента. - Обнаружен кем-либо в другом подразделении ИТ: этот специалист регистрирует инцидент в системе регистрации инцидентов или докладывает о нем в Службу Service Desk. Необходимо избегать двойной регистрации одного инцидента. Поэтому при регистрации инцидента следует проверить, нет ли аналогичных открытых инцидентов: - Если есть (и они касаются того же инцидента), информация об инциденте обновляется или же инцидент регистрируется отдельно и устанавливается связь (привязка) к главному инциденту; при необходимости изменяется степень воздействия и приоритет, и добавляется информация о новом пользователе. - Если нет (отличается от открытого инцидента), производится регистрация нового инцидента. В обоих случаях продолжение процесса одинаково, хотя в первом случае последующие действия гораздо проще. При регистрации инцидента производятся следующие действия: - Назначение номера инцидента: в большинстве случаев система автоматически назначает новый (уникальный) номер инцидента. Часто этот номер сообщается пользователю, чтобы он мог ссылаться на него при дальнейших контактах. - Запись базовой диагностической информации: время, признаки (симптомы), пользователь, сотрудник, принявший вопрос в обработку, место произошедшего инцидента и информация о затронутой услуге и/или технических средствах. - Запись дополнительной информации об инциденте: добавляется информация, например, из скрипта (script) или процедуры опроса или из Конфигурационной Базы Данных – CMDB (обычно на основе взаимоотношений Конфигурационных Единиц, определенных в CMDB). - Объявление сигнала тревоги: если происходит инцидент, имеющий высокую степень воздействия, например, сбой важного сервера, производится предупреждение других пользователей и руководства. Классификация инцидентов направлена на определение его категории для облегчения мониторинга и составления отчетов. Желательно, чтобы опции классификации были как можно шире, но при этом требуется более высокий уровень ответственности персонала. Иногда пытаются объединить в одном перечне несколько аспектов классификации, таких, как тип, группа поддержки и источник. Это часто вносит путаницу. Лучше использовать несколько коротких перечней. В данном разделе рассматриваются вопросы, относящиеся к классификации. Категория
Прежде всего, инцидентам присваивается категория и подкатегория, например, исходя из предполагаемого источника инцидента или соответствующей группы поддержки: - Центральная процессинговая система – подсистема доступа, центральный сервер, приложение. - Сеть – маршрутизаторы, сегменты, концентратор (hub), IP-адреса. - Рабочая станция – монитор, сетевая карта, дисковод, клавиатура. - Использование и функциональность – услуга (сервис), возможности системы, доступность, резервное копирование (back-up), документация. - Организация и процедуры – заказ, запрос, поддержка, оповещение (коммуникации). - Запрос на Обслуживание – запрос пользователя в Службу Service Desk на поддержку, предоставление информации, документации или оказание консультации. Это может быть выделено в отдельную процедуру или обработано таким же образом, как реальный инцидент. Приоритет
После этого назначается приоритет, чтобы быть уверенными, что группа поддержки уделит инциденту необходимое внимание. Приоритет - это номер, определяющийся срочностью (насколько быстро это должно быть исправлено) и степенью воздействия (какой ущерб будет нанесен, если не исправить быстро). Приоритет = Срочность х Степень воздействия. Услуги (сервисы)
Для определения услуг, подвергшихся воздействию инцидента, может быть использован перечень существующих договоренностей (соглашений) об Уровне Услуг – SLA. Этот перечень позволит также установить время эскалации для каждой из услуг, определенных в SLA. Группа поддержки
Если Служба Service Desk не может разрешить инцидент незамедлительно, то определяется группа поддержки, которая будет заниматься разрешением инцидента. Основой для распределения (маршрутизации) инцидентов часто является информация о категориях. При определении категорий может потребоваться рассмотрение структуры групп поддержки. Правильное распределение инцидентов имеет существенное значение для эффективности Процесса Управления Инцидентами. Поэтому одним из ключевых показателей эффективности[68]
(KPI) Процесса Управления Инцидентами может быть число неправильно распределенных обращений. Сроки решения
С учетом приоритета и соглашения SLA пользователь информируется о максимальном расчетном времени разрешения инцидента. Эти сроки также фиксируются в системе. Идентификационный номер инцидента
Абонент информируется о номере инцидента для его точной идентификации при последующих обращениях. Статус
Статус инцидента указывает на его положение в процессе обработки инцидента. Примерами статусов могут быть: - новый; - принят; - запланирован; - назначен; - активный; - отложен; - разрешен; - закрыт. После классификации проводится проверка, не возникал ли аналогичный инцидент ранее и нет ли готового решения или обходного пути. Если инцидент имеет те же признаки, что и открытая проблема или известная ошибка, то может быть установлена связь с ними. Служба Service Desk или группа поддержки направляет инциденты, не имеющие готового решения или выходящие за пределы компетенции работающего с ним сотрудника, группе поддержки следующего уровня с большим опытом и знаниями. Эта группа исследует и разрешает инцидент или направляет его группе поддержки очередного уровня. В процессе разрешения инцидента различные специалисты могут обновлять регистрационную запись о нем, изменяя текущий статус, информацию о выполненных действиях, пересматривая классификацию и обновляя время и код работавшего сотрудника. После успешного завершения анализа и разрешения инцидента сотрудник записывает решение в систему. В некоторых случаях необходимо направить Запрос на Изменение (RFC) в Процесс Управления Изменениями. В наихудшем случае, если не найдено никакого решения, инцидент остается открытым. После реализации решения, удовлетворяющего пользователя, группа поддержки направляет инцидент обратно в Службу Service Desk. Эта служба связывается с сотрудником, сообщившим об инциденте, с целью получения подтверждения об успешном решении вопроса. Если он это подтверждает, то инцидент может быть закрыт; в противном случае процесс возобновляется на соответствующем уровне. При закрытии инцидента необходимо обновить данные об окончательной категории, приоритете, сервисах (услугах), подвергшихся воздействию инцидента и Конфигурационной Единице (CI), вызвавшей сбой. В большинстве случаев ответственной за мониторинг хода решения является Служба Service Desk, как "владелец" всех инцидентов. Эта служба должна также информировать пользователя о состоянии инцидента. Обратная связь с пользователем может быть уместной после изменения статуса, например, направлении инцидента на следующую линию поддержки, изменении расчетного времени решения, эскалации и т. д. Во время мониторинга возможна функциональная эскалация к другим группам поддержки или иерархическая эскалация для принятия руководящих решений. Основой контроля процесса являются отчеты для различных целевых групп. Руководитель Процесса Управления Инцидентами является ответственным за эти отчеты, а также за составление списка рассылки и графика составления отчетов. Отчеты могут включать специализированную информацию для следующих функциональных подразделений: - Руководителю Процесса Управления Инцидентами отчет необходим для: - идентификации недостающих звеньев процесса; - идентификации нарушений исполнения соглашений об Уровне Услуг (SLA); - отслеживания хода выполнения процесса; - определения тенденций развития. - Руководство Линейными ИТ-подразделениями – отчет для руководства группы поддержки; он также может быть полезен в Управлении ИТ-подразделениями. Отчет должен содержать следующую информацию: - прогресс в решении инцидентов; - время разрешения инцидентов в различных группах поддержки. - Управления Уровнем Сервисов (Услуг) – отчет должен, прежде всего, содержать информацию о качестве предоставляемых услуг. Руководитель Процесса Управления Уровнем Услуг должен получать всю информацию, необходимую для составления Отчетов об Уровне Услуг перед заказчиками. Отчеты для заказчиков должны предоставлять информацию о том, выполняются ли соглашения в отношении Уровня Сервисов (услуг) в рамках Процесса Управления Инцидентами. - Руководителей других процессов ИТ Сервис-менеджмента – отчеты для руководителей других процессов должны быть, в первую очередь, информативными, то есть содержать всю необходимую им информацию. Например, Процесс Управления Инцидентами на основе регистрационных записей об инцидентах может предоставлять следующую информацию: - число обнаруженных и зарегистрированных инцидентов; - число разрешенных инцидентов, с разделением по времени разрешения; - статус и число неразрешенных инцидентов; - инциденты с разбивкой по периодам возникновения, группам заказчика, группам поддержки и временем разрешения в соответствии с соглашением (SLA); - инциденты с разбивкой по категориям, приоритетам и группам поддержки и др. Для успешного Управления Инцидентами необходимо следующее: - Актуальная Конфигурационная База Данных (CMDB), помогающая оценить степень воздействия и срочность инцидентов. Эта информация также может быть получена от пользователя, но в этом случае она, возможно, будет менее полной и достаточно субъективной, что приведет к увеличению времени разрешения инцидентов. - База знаний[69]
. Например, актуальная база данных по проблемам/известным ошибкам, описывающая способ распознавания инцидентов, имеющиеся решения и обходные пути. Она также может включать аналогичные базы знаний от поставщиков. - Соответствующую автоматизированную систему регистрации, отслеживания и мониторинга инцидентов. Дополнительно необходимо тесное взаимодействие с Процессом Управления Уровнем Сервисов (Услуг) для определения требуемых приоритетов и времени разрешения инцидентов. Для оценки производительности процесса необходимо четко определить контрольные параметры и измеряемые оценки, часто называемые показателями эффективности. Отчет по этим показателям производится регулярно, например раз в неделю, чтобы получить картину изменений, по которой можно было бы определить тенденции. Примерами таких параметров являются: - общее количество инцидентов; - среднее время разрешения инцидентов; - среднее время разрешения инцидентов по приоритетам; - среднее число инцидентов, разрешенных в рамках соглашений (SLA); - процент инцидентов, разрешенных первой линией поддержки (без направления в другие группы); - средняя стоимость поддержки на инцидент; - число решенных инцидентов на одно рабочее место или на одного сотрудника службы Service Desk; - инциденты, решенные без посещения пользователя (удаленно); - число (или процент) инцидентов с первоначально некорректной классификацией; - число (или процент) инцидентов, неправильно распределенных в группы поддержки. Реализация процессов проходит в горизонтальной плоскости через иерархическую структуру организации. Это возможно только при четком определении ответственности и полномочий, связанных с реализацией процессов. Для повышения гибкости может быть использован ролевой подход (т.е. определение ролей). В небольших организациях или в целях снижения общих расходов возможно комбинирование ролей, например, совмещение ролей Руководителя Процессов Управления Изменениями и Управления Конфигурациями. Руководитель Процесса Управления Инцидентами
Во многих организациях роль Руководителя Управления Инцидентами играет менеджер Службы Service Desk. В сферу ответственности Руководителя Процесса Управления Инцидентами включается следующее: - мониторинг эффективности и рациональности работы[71]
процесса; - контроль работы групп поддержки; - составление рекомендаций по совершенствованию работы процесса; - развитие и сопровождение системы Управления Инцидентами. Персонал групп поддержки
- Первая линия поддержки несет ответственность за регистрацию, классификацию, сопоставление (привязку), распределение по группам поддержки, разрешение и закрытие инцидентов. - Остальные группы поддержки, прежде всего, принимают участие в расследовании, диагностике и разрешении инцидентов в рамках установленных приоритетов. Затраты, связанные с Управлением Инцидентами, включают первоначальные затраты на внедрение (например, расходы на разработку процесса, обучение и инструктаж персонала), выбор и закупку инструментальных средств[72]
поддержки процесса. Выбор инструментальных средств может занять значительное количество времени. Кроме того, существуют операционные расходы, связанные с оплатой работы персонала и использованием инструментальных средств. Эти затраты во многом зависят от структуры Управления Инцидентами, диапазона видов деятельности, включенных в процесс, сфер ответственности и числа подразделений. При внедрении Управления Инцидентами могут возникнуть следующие проблемы: - Пользователи и ИТ-специалисты работают в обход процедур Управления Инцидентами – если пользователи будут устранять возникающие ошибки сами или напрямую связываться со специалистами, не следуя установленным процедурам, ИТ-организация не получит информацию о реально предоставляемом Уровне Услуг, числе ошибок и многое другое. Отчеты руководству также не будут адекватно отражать ситуацию. - Перегруженность инцидентами и откладывание "на потом" – при неожиданном росте количества инцидентов для правильной регистрации может не оказаться достаточно времени, т. к. до окончания ввода информации об инциденте от одного пользователя возникает необходимость обслуживать следующего. В этом случае ввод описания инцидентов может производиться недостаточно точно и процедуры по распределению инцидентов по группам поддержки не будут выполняться должным образом. В результате решения получаются некачественными и рабочая нагрузка увеличивается еще больше. В случаях, если число открытых инцидентов начинает интенсивно расти, процедура экстренного выделения дополнительных ресурсов внутри организации может предотвратить перегрузку персонала. - Эскалация – как известно, в рамках Процесса Управления Инцидентами возможна эскалация инцидентов. Слишком большое число эскалаций может оказать отрицательное воздействие на работу специалистов, которые из-за этого отрываются от своей запланированной работы. - Отсутствие Каталога Услуг и Соглашений об Уровне Сервисов (SLA) – если поддерживаемые услуги и продукты недостаточно точно определены, тогда специалистам, вовлеченным в Управление Инцидентами, бывает трудно обоснованно отказать пользователям в помощи. - Недостаточная приверженность[73]
процессному подходу со стороны руководства и персонала – решение инцидентов с помощью процессного подхода обычно требует изменения культуры и более высокого уровня ответственности за свою работу со стороны персонала. Это может вызвать серьезное сопротивление внутри организации. Эффективное Управление Инцидентами требует от сотрудников понимания и реальной приверженности процессному подходу, а не просто участия. Как было сказано в предыдущей главе, Процесс Управления Инцидентами начинает действовать с появлением инцидента и прекращает свою работу после исправления ситуации. Это означает, что корневая причина возникновения инцидента не всегда бывает установлена и инцидент может повториться снова. Для выяснения корневых причин возникновения как существующих, так и потенциальных ошибок в предоставлении услуг, в рамках Процесса Управления Проблемами производится изучение инфраструктуры и имеющихся регистрационных данных, включая базу данных инцидентов. Такие исследования необходимы из-за сложного и распределенного характера инфраструктуры, когда связи между инцидентами не всегда бывают очевидными. Например, причиной проблемы могут стать сразу несколько ошибок, и в то же время несколько проблем могут быть связаны с одной и той же ошибкой. Вначале надо определить причину возникновения проблемы. После того, как корневая причина определена, проблема переходит в разряд известных ошибок и для устранения этой причины можно направить Запрос на Изменение[74]
. Но даже после этого известные ошибки будут отслеживаться и контролироваться в рамках Процесса Управления Проблемами. Поэтому следует вести регистрацию всех идентифицированных известных ошибок, их симптомов и имеющихся решений. На рис 5.1 показаны взаимосвязи между проблемой, известной ошибкой и Запросом на Изменение и даны определения этих терминов.
Рис. 5.1. Отношения между проблемами и известными ошибками (источник OGC) Процесс Управления Проблемами поддерживает Процесс Управления Инцидентами, предоставляя ему обходные решения и быстрые исправления[75]
, но при этом не неся прямой ответственности за разрешение инцидента. Управление Инцидентами помогает быстро исправить ошибку любыми доступными средствами, включая обходные решения, в то время как Управление Проблемами занимается поиском причины произошедшего и ее устранением. Инцидент может никогда "не стать" проблемой. Однако кроме самого инцидента, может быть определена связанная с ним проблема. Поэтому работа над проблемой может помочь в разрешении текущего инцидента, если он еще открыт. На рис. 5.2 показаны отношения между инцидентами, проблемами, известными ошибками и изменениями. Управление Инцидентами Инциденты Регистрация Информация о привязке/ сопоставлении Управление Проблемами Информация о привязке/ сопоаавлении Обходные решения Обходные решения и быстрые решения («заплатки») Информация об ошибках Регистрация проблем Тенденции, периодичность, влияние Проблемы Расследованиу! диатоаика Контроль ошибок , Регистрация ошйок Известные ошибки Запросы на Изменения Управление Изменениями Решение Контроль проблем Идентификация и регистрация известных ошибок База Данных пробле/.i Поиск решения Описание выбранного решения Запрос на изменение f Управление Л I Изменениями J Оценка проблемы/ анализ peiyAbiaToa внедрения Изменение выполнено? Закрытие проблемы База Данных проблем ????????????????????????????? Рис. 5.5. Контроль ошибок (ИСТОЧНИК: OGC) Рис. 5.2. Отношения между Процессами Управления Инцидентами, Управления Проблемами и Управления Изменениями Целью Процесса Управления Проблемами является установление корневой причины возникновения проблемы и, как следствие, предотвращение инцидентов. Управление Проблемами включает в себя проактивные (упреждающие) и реактивные виды деятельности. Задачей реактивных составляющих Процесса Управления Проблемами является выяснение корневой причины прошлых инцидентов и подготовка предложения по ее ликвидации. Проактивные Управление Проблемами помогает предотвратить инциденты путем определения слабых мест в инфраструктуре и подготовки предложений по ее усовершенствованию. Управление Проблемами гарантирует, что: - существующие и регулярно возникающие ошибки[76]
идентифицированы, документированы и отслеживаются; - симптомы ошибок, постоянные или временные решения документируются; - подаются Запросы на Изменения с целью модификации инфраструктуры; - предотвращается возникновение новых инцидентов; - создаются отчеты о качестве инфраструктуры ИТ и самого процесса. Управление Проблемами позволяет быстро улучшить качество услуг путем значительного сокращения количества инцидентов и уменьшения рабочей нагрузки на ИТ-организацию. Некоторые из преимуществ данного процесса состоят в следующем: - Улучшение качества ИТ-услуг и Управления – результат документирования ошибок и/или их устранения. - Повышение производительности труда пользователей – за счет улучшения качества услуг. - Повышение производительности труда персонала – наличие документированных решений проблем позволяет даже менее опытным участникам Процесса Управления Инцидентами разрешать инциденты быстрее и эффективнее. - Улучшение репутации ИТ-услуг – в результате улучшения стабильности услуг заказчики с большим желанием сотрудничают с ИТ-организацией в новых сферах бизнеса. - Совершенствование знаний в области Управления, эффективное обучение – Процесс Управления Проблемами позволяет хранить исторические данные[77]
, которые используются при определении тенденций и помогают принять меры по предотвращению новых инцидентов. Исторические данные также можно использовать при проведении исследований и диагностирования, а также, при создании Запросов на Изменения. - Улучшение регистрации инцидентов – Управление Проблемами вводит стандарты на регистрацию и классификацию инцидентов с целью эффективного определения проблем и их симптомов. Это также помогает улучшить составление отчетов об инцидентах. - Более высокая доля инцидентов, разрешенных на первой линии поддержки – поскольку Процесс Управления Проблемами разрабатывает решения для ликвидации инцидентов и проблем, а обходные решения можно найти в базе знаний, то первая линия поддержки с большим успехом сама разрешает инциденты. Входами для Процесса Управления Проблемами являются: - детальные описания инцидентов; - обходные решения, найденные Процессом Управления Инцидентами; - детали конфигурации из Конфигурационной Базы Данных (CMDB); - подробная информация от производителя используемых в инфраструктуре продуктах, включая известные ошибки в этих продуктах и технические детали; - подробная информация об инфраструктуре и ее поведении, такая как записи о имеющихся мощностях, замеры производительности, отчеты о соблюдении Уровней Услуг и так далее. Основными видами деятельности в рамках Процесса Управления Проблемами являются: - контроль проблем: определение и исследование проблем; - контроль ошибок: отслеживание известных ошибок и подача Запросов на Изменения (RFC); - проактивное Управление Проблемами: предотвращение инцидентов путем совершенствования инфраструктуры; - предоставление информации: отчеты по серьезным проблемам и достигнутым результатам. Выходами процесса являются: - известные ошибки; - Запросы на Изменения (RFC); - новые регистрационные данные о проблемах (обновленные с учетом информации о способах решения и/или обходных решениях); - закрытые после устранения причины проблемы регистрационные записи; - информация для руководства.
Рис. 5.3. Управление Проблемами среди других процессов Управление Инцидентами является важным партнером Процесса Управления Проблемами. Эффективная регистрация инцидентов важна для успешного Управления Проблемами, так как эта информация используется при идентификации проблемы. Управление Проблемами поддерживает Процесс Управление Инцидентами. Процесс Управления Проблемами изучает проблемы и, пока не будет найдено решение, Управлению Инцидентами предлагаются обходные решения для работы над инцидентом. После установления причины и определения Известной ошибки, может быть предложено быстрое решение ("заплатка")[78]
, которое поможет предотвратить возникновение инцидентов на некоторое время или уменьшит их негативные последствия. Управление Проблемами может подать Запрос на Изменение, который приведет к окончательному решению. Примечание. Обходные решения могут создаваться и в Процессе Управления Инцидентами, и в Процессе Управления Проблемами. Управление Изменениями отвечает за контролируемое проведение изменений, включая Запросы на Изменения для устранения проблем, предложенные Процессом Управления Проблемами. Управление Изменениями несет ответственность за определение степени воздействия изменения и ресурсов, необходимых для его реализации, а также за планирование, согласование и оценку запрашиваемых изменений. Кроме того, Управление Изменениями информирует Процесс Управления Проблемами о ходе работ и о завершении корректирующих изменений. Оценка этим изменениям дается совместно с Процессом Управления Проблемами. Итогом работы является Анализ результатов внедрения[79]
, после которого в рамках подпроцесса Контроля ошибок может быть закрыта известная ошибка, а также относящиеся к ней (открытые) инциденты. Процесс Управления Конфигурациями предоставляет важную информацию об элементах инфраструктуры, документации, конфигурации программного и аппаратного обеспечения, ИТ-сервисах и других отношениях типа "связан с", "использует" и "является частью". Эти отношения являются исключительно важными для решения проблем. Процесс Управления Доступностью нацелен на планирование и реализацию согласованных Уровней Доступности. Управление Проблемами оказывает поддержку Управлению Доступностью, определяя и устраняя причины недоступности услуг. Процесс Управления Доступностью направлен на разработку архитектуры и проектирование инфраструктуры, его задача — предупреждать появление проблем и инцидентов путем оптимизации планирования доступности услуг и ее мониторинга. Управление Мощностями позволяет оптимизировать использование ИТ-ресурсов. Данный процесс предоставляет Управлению Проблемами важную информацию, которую можно использовать для определения проблем. Управление Проблемами оказывает поддержку Управлению Мощностями, устанавливая причины соответствующих проблем и устраняет их. Управление Уровнем Услуг включает в себя работы по согласованию и заключению Соглашений о Качестве ИТ-услуг. Управление Уровнем Услуг передает в Процесс Управления Проблемами информацию, которая используется при определении проблем. Процедуры Процесса Управления Проблемами должны поддерживать предоставление услуг в соответствии с согласованными стандартами качества. Эту же роль Управление Проблемами играет в Процессах Управления ИТ-финансами и Управления Непрерывностью ИТ-услуг. Целью этого вида деятельности является выявление проблем и изучение их причин. Контроль проблем должен преобразовать проблему в известную ошибку путем диагностирования неизвестной причины ее возникновения. На рис. 5.4 показаны действия, выполняемые в рамках контроля проблемы.
Рис. 5.4. Контроль проблем (источник: OGC) Идентификация и регистрация проблемы
В принципе, любой инцидент, возникший по неизвестной причине, может быть связан с проблемой. На практике это имеет смысл делать только тогда, когда инцидент повторяется, возможно его повторение или если это единичный, но серьезный инцидент. Деятельность по "идентификации проблем" часто выполняют Координаторы проблем. Однако бывает так, что персонал, изначально не вовлеченный в эту работу, например, специалисты по Управлению Мощностями, тоже может выявлять проблемы. Такие "находки" также следует регистрировать как проблемы. Регистрационные детали проблем схожи с деталями инцидентов, но в случае проблемы не нужно включать в описание информацию о пользователе и т.д. Однако инциденты, связанные с конкретной проблемой, следует идентифицировать и соответствующим образом регистрировать. Ниже даются примеры случаев, когда могут быть идентифицированы проблемы: - Анализ инцидентов показывает, что некоторый инцидент повторяется, возникает большое количество инцидентов или возникает негативная тенденция. - Анализ инфраструктуры позволил определить ее слабые места, где могут произойти новые инциденты (возможно, это проводилось средствами Процессов Управления Доступностью и Управления Мощностями). - Произошел серьезный инцидент, требующий структурного решения для предотвращения его повторения в будущем. - Существует угроза срыва Уровня Услуг, согласованного с заказчиком (по показателям производительности, мощности ИТ-средств, затрат и т. д.) - Нельзя установить связь между новыми инцидентами и уже известной проблемой или ошибкой. - Нельзя установить связь между зарегистрированными инцидентами и любой из известных проблем или ошибок. Анализ тенденций позволяет обнаружить области, которым требуется особое внимание. Необходимые для этого дополнительные ресурсы нужно обосновать с позиции издержек и выгод для организации. Например, определить области, которым требуется более действенная поддержка, и понять, насколько они важны для предоставляемых услуг. Такая оценка может базироваться на "болевом показателе" инцидентов, в котором учитываются: - издержки, которые несет бизнес из-за инцидентов; - количество инцидентов; - количество пользователей и бизнес-процессов, затронутых инцидентами; - время и затраты на разрешение инцидентов. Классификация и назначение
Проблемы можно классифицировать по областям (категориям). Классификация проблемы выполняется одновременного с анализом степени ее воздействия, т. е. уровня серьезности проблемы и ее влияния на услуги (срочность и степень воздействия). Вслед за этим проблеме присваивается приоритет, точно так же, как в Процессе Управления Инцидентами. Затем на основе результатов классификации за проблемой закрепляются ресурсы и персонал и определяется время, необходимое для ее решения. Классификация проблемы включает в себя следующее: - Категория: определение области, например, программное или аппаратное обеспечение; - Степень воздействия на бизнес-процесс; - Срочность: допустимая задержка в решении проблемы; - Приоритет: показатель, объединяющий срочность, степень воздействия, риск и необходимые ресурсы; - Статус: например, проблема, известная ошибка и т. д. Классификация не является статичной, она может меняться на протяжении жизненного цикла проблемы. Например, наличие обходного решения или быстрого решения поможет снизить срочность проблемы, в то время как новые инциденты могут привести к усилению степени воздействия проблемы. Расследование и диагностика
Расследование и диагностика являются итеративными фазами процесса, они неоднократно повторяются, каждый раз приближаясь все ближе к намеченному результату. Часто делаются попытки воспроизвести инцидент в условиях тестирования. Для решения проблемы могут потребоваться дополнительные знания, например, для анализа и диагностики проблемы можно привлечь специалистов из группы поддержки. Проблемы возникают не только из-за программных или технических средств. Они могут быть вызваны ошибками в документации, ошибками персонала или процедурными ошибками, такими как выпуск неправильной версии программного обеспечения. Поэтому желательно включать описания процедур в Конфигурационную Базу Данных и проводить контроль их версий. В то же время многие ошибки связаны с компонентами ИТ-инфраструктуры. После того как установлена причина проблемы, определены Конфигурационные Единицы или группы единиц, ее вызвавшие, установлена связь между Конфигурационной Единицей и инцидентом (инцидентами), становиться возможным определить Известную ошибку. После этого Управление Проблемами продолжит свою работу, выполняя функции контроля ошибок. Источники ошибок в других средах
В большинстве случае ошибки выявляются только тогда, когда система находится в реальной рабочей среде. Однако продукты, поступающие из среды разработки (от внешних поставщиков и внутренних разработчиков), также могут содержать известные ошибки (дефекты). Примечание: для компаний-разработчиков среда разработки программного обеспечения является их промышленной средой. Обычно разработчики и поставщики должны сообщать, какие ошибки содержатся в каждой конкретной версии. Отраслевые издания часто предоставляют информацию об известных ошибках в популярных программных продуктах. Некоторые производители поставляют свои продукты вместе с базами данных, содержащими информацию об имеющихся в продуктах известных ошибках. Если известные ошибки в продукте не представляют серьезной опасности или если бизнес настаивает на запуске релиза, несмотря на имеющиеся недостатки, то может быть принято решение об использовании разработанного продукта в производственной среде, но при этом необходимо, чтобы известные ошибки были учтены в рамках деятельности по Контролю ошибок. В этом случае следует организовать взаимодействие с Процессом Управления Инцидентами, чтобы быстро распознавать инциденты, произошедшие в результате внедрения таких продуктов. В случаях необходимости также могут быть предоставлены обходные решения или быстрые исправления. Перед началом внедрения продукта Процессу Управления Изменениями следует принять решение о приемлемости имеющихся известных ошибок. Часто такое решение принимается под давлением, так как пользователи ждут появления новой функциональности. Деятельность по Контролю ошибок заключается в ведении мониторинга и исправлении известных ошибок до момента их полного устранения (в тех случаях, когда это возможно и целесообразно). Эта задача решается путем подачи Запроса на Изменение (RFC) в Процесс Управления Изменениями и оценки внесенных изменений с помощью Анализа результатов внедрения (PIR). В рамках контроля ошибок осуществляется деятельность по мониторингу всех известных ошибок с момента их идентификации и до устранения. К работе по Контролю ошибок привлекаются многие подразделения, как операционной среды, так и из среды разработок.
Рис. 5.5. Контроль ошибок (источник: OGC) Идентификация и регистрация ошибок
После определения причины проблемы и связанной с ней Конфигурационной Единицы, проблеме присваивается статус "Известной ошибки" и начинается деятельность по Контролю ошибок. Во многих случаях уже имеется обходное решение для проблемы, даже если ошибка найдена самими разработчиками. Но в некоторых случаях обходное решение нужно найти, а затем передать его в Процесс Управления Инцидентами, если там еще имеются открытые инциденты. Это обходное решение также можно использовать во время сопоставления инцидентов[80]
. Поиск решения
Персонал, участвующий в Управлении Проблемами, определяет, что необходимо сделать для разрешения известной ошибки. Специалисты сравнивают различные решения, принимая во внимание Соглашения об Уровне Услуг (SLA), возможные издержки и выгоды. Они определяют степень влияния и срочность Запросов на Изменения. Все работы по выработке решения должны быть зафиксированы в системе, у персонала должны быть средства для мониторинга проблем и определения их статуса. Срочное исправление
Во время работы может потребоваться разрешение на выполнение срочного исправления, если известная ошибка ведет к возникновению серьезных инцидентов. Если для выполнения экстренного или быстрого исправления нужно модифицировать инфраструктуру, то вначале следует подать Запрос на Изменение. Если ситуация очень серьезная и задержка решения недопустима, то приводится в действие процедура проведения срочных изменений. Определение окончательного решения
На предыдущих этапах происходит выбор оптимального решения. Однако может быть принято решение не исправлять известную ошибку, например, по причине экономической нецелесообразности. Например, компания, у которой есть проблемы с собственными разработками системы ERP, приостанавливает любые исправления кодов существующей системы, так как принято стратегическое решение о переходе на SAP к концу года. В этом и других аналогичных случаях полученные преимущества не перевешивают затраты на исправления. Или же в другом случае степень воздействия ошибки может оказаться приемлемой, инцидент может оказаться легким для исправления или же вероятность его повторения невысока. В некоторых случаях исправление известной ошибки вообще невозможно без приложения усилий, несоразмерных проблеме. Но какое бы решение не было принято, оно должно быть отражено в системе, чтобы его можно было использовать в Процессе Управления Инцидентами. После окончания этапа выбора существует достаточно информации для подачи Запроса на Изменение. Далее исправление известной ошибки будет произведено в рамках Процесса Управления Изменениями. Анализ результатов внедрения
[81]
(PIR)
Изменение, предназначенное для устранения известной ошибки, должно быть рассмотрено при анализе результатов внедрения до закрытия проблемы. Если изменение дало ожидаемый результат, проблема может быть закрыта, и в базе данных о проблемах ее статус будет изменен на статус "решена". Управление Инцидентами будет проинформировано об этом и инциденты, связанные с этой проблемой, тоже могут быть закрыты. Примечание: Во многих организациях процесс реализован таким образом, что проблема закрывается только после того, как будут закрыты связанные с ней инциденты (и закрытие проверено заказчиком), иначе если инциденты не удается закрыть, то проблему будет необходимо открывать снова. Отслеживание и мониторинг
Данная задача предполагает выполнение мониторинга хода работ по разрешению проблем и известных ошибок на всех этапах Контроля проблем и Контроля ошибок. Цели состоят в следующем: - Определить, изменилась ли степень влияния или срочность проблемы, и на основании этого производить корректировку приоритета проблемы. - Вести мониторинг процесса выработки и реализации решения и контролировать правильность исполнения Запроса на Изменение. По этой причине Управление Изменениями регулярно передает информацию о состоянии Запросов на Изменение в Контроль ошибок. Предоставление информации
В течение всего процесса информация об обходных решениях и быстрых исправлениях передается в Управление Инцидентами. Пользователи также могут информироваться об этом. Хотя данные предоставляет Процесс Управления Проблемами, их распространением занимается Служба Service Desk. Управление Проблемами использует Конфигурационную Базу Данных, а также Соглашения об Уровне Услуг, для уточнения, какую информацию и кому следует предоставлять. 5.4.3. Проактивное Управление Проблемами
Проактивное Управление Проблемами (т. е. предупреждающее появление проблемы) имеет дело с вопросами качества инфраструктуры. Оно сосредоточено на анализе тенденций и выявлении потенциальных угроз инцидентов до того, как они произойдут. Это достигается путем изучения слабых и перегруженных компонентов инфраструктуры. Если таких областей несколько, тогда делается попытка предотвращения появления в них ошибок, которые наблюдались в других местах. Слабые места инфраструктуры должны быть выявлены и изучены. 5.5 Управление Процессом
5.5.1. Отчеты об Управлении и Ключевые показатели эффективности Успешное Управление Проблемами проявляется в: - сокращении количества инцидентов в результате разрешения проблем; - сокращении времени, требуемом для разрешения проблем; - уменьшении других затрат, связанных с разрешением проблем. Параметры процесса также могут быть включены в отчеты для внутренних целей Управления, для оценки и контроля эффективности Управления Проблемами. Отчеты об Управлении Проблемами могут быть достаточно объемными и охватывать следующие аспекты: - Отчеты о времени исполнения: разделенные на Контроль проблем, Контроль ошибок и проактивное Управление Проблемами, а также разделенные между группой поддержки и поставщиком. - Качество продукта: детальная информация об инциденте, проблеме и известной ошибке может помочь выявлению продуктов, подверженных частым ошибкам, и установлению, могут ли поставщики в этом плане принять на себя соответствующие контрактные обязательства. - Эффективность[82]
Процесса Управления Проблемами: точное количество инцидентов до и после решения проблемы, зарегистрированные проблемы, количество поданных Запросов на Изменения и решенных известных ошибок. - Баланс между реактивным и проактивным Управлением Проблемами: увеличение объема проактивного Управления Проблемами по сравнению с простым реагированием на инциденты свидетельствует о большей зрелости процесса. - Качество разработанных продуктов: продукты, переданные от разработчиков, должны иметь высокое качество, иначе они могут создать новые проблемы. Для мониторинга качества важны отчеты о новых продуктах и имеющихся в них известных ошибках. - Статус и план работ по открытым проблемам: итоговый отчет о том, что было сделано и что будет сделано для разрешения наиболее серьезных проблем, включая запланированные Запросы на Изменения, необходимое время и ресурсы. - Предложения по улучшению Процесса Управления Проблемами: если отчетная информация по перечисленным выше аспектам указывает на то, что процесс не соответствует Плану обеспечения качества услуг, нужно предлагать меры по совершенствованию процедур регистрации, расследования проблем, выполнения проактивных действий, а также для выделения дополнительных ресурсов. В планировании и улучшении процесса могут помочь регулярные аудиторские проверки. Содержание отчетов зависит от сферы действия Процесса Управления Проблемами. Если в сферу действия процесса попадают продукты из среды разработки, то Управление Проблемами может определять известные ошибки и вести их мониторинг даже на этапе разработки программного обеспечения. 5.5.2. Критические факторы успеха
Успешное Управление Проблемами зависит от следующих факторов: - Эффективная автоматизированная регистрация инцидентов и эффективный контроль за состоянием инфраструктуры. - Наличие реалистичных целей и максимальное использование знаний и опыта персонала, например, наличие соглашения о возможности привлечения специалистов в обусловленное время и резервировании достаточного времени на их работу по исследованию корневых причин проблем. - Эффективность взаимодействия Управления Проблемами и Управления Инцидентами. При распределении заданий и работ нужно учитывать конфликт интересов этих двух процессов: "тушение пожара" в рамках Управления Инцидентами и необходимость выяснения корневых причин в рамках Управления Проблемами. Работа процессов происходит в горизонтальной плоскости, проходя через различные иерархические (вертикальные) подразделения организации и функциональные обязанности в рамках отделов. Эффективная работа возможна только при четком определении ответственности и полномочий, связанных с реализацией процессов. Для повышения гибкости может быть использован ролевой подход. Если организация небольшая или имеются соответствующие экономические ограничения, то возможно комбинирование ролей, например, Руководителя Процесса Управления Проблемами и Процесса Управления Уровнем Сервиса. Последний пункт в разделе 5.5.2 объясняет, почему многие организации избегают объединения ролей руководителя службы Service Desk/Управления Инцидентами и Руководителя Процесса Управления Проблемами. Руководитель Процесса Управления Проблемами
Руководитель Процесса несет ответственность за такие виды деятельности по Управлению Проблемами, как: - разработка и поддержка подпроцессов Контроля проблем и Контроля ошибок; - оценка эффективности и рациональности[83]
работ по Контролю проблем и Контролю ошибок; - предоставление Управленческой Информации; - управление Персоналом, участвующим в Процессе Управления Проблемами; - обеспечение необходимых ресурсов; - разработка и совершенствование систем Контроля Проблем и Контроля Ошибок; - анализ работы и оценка эффективности проактивного Управления Проблемами. Роли поддержки деятельности по Управлению Проблемами
Ответственность персонала, выполняющего роли по решению проблем: - Реактивное Управление: - выявление и регистрация проблемы путем анализа информации об инцидентах; - изучение проблем на основе их приоритетности; - подача Запросов на Изменение; - мониторинг устранения ошибок; - подготовка рекомендаций по обходным решениям и быстрым исправлениям для Управления Инцидентами. - Проактивное Управление: - определение тенденций; - подача Запросов на Изменения; - предотвращение распространения проблем на другие системы. В дополнение к расходам на средства поддержки и диагностики необходимо учитывать расходы на персонал. Кроме затрат на содержание собственного ИТ-персонала, участвующего в Управлении Проблемами, есть еще расходы на специалистов, привлеченных из сторонних организаций. Однако следует заметить, что все связанные с этим расходы обычно успешно окупаются через получаемые преимущества. На следующие вопросы следует обратить внимание при реализации Процесса Управления Проблемами и, по возможности, их избежать: - Плохая связь между Процессами Управления Инцидентами и Управления Проблемами: если связь между работами над инцидентами, проблемами и известными ошибками неадекватна, Процесс Управления Инцидентами не будет знать об обходных решениях для проблем, а Процессу Управления Проблемами будет трудно выполнять оценку и мониторинг проблем. В результате этого будет существовать меньше доступной информации об инфраструктуре и данных о предыстории проблем. Поэтому успешное Управление Проблемами во многом зависит от этого взаимодействия. - Недостаточно полная передача информации об известных ошибках из среды разработки в реальную рабочую среду: информация о программной и технической инфраструктуре, передаваемая в промышленную среду, должна дополняться подробной информацией об известных ошибках. Передача такой информации при развертывании системы позволяет сэкономить время, затрачиваемое на поиски уже известных ошибок. Поэтому должен существовать эффективный обмен данными между двумя системами регистрации проблем (в тестовой и промышленной среде) или должна быть создана единая система. - Отсутствие понимания важности процесса: если существовавший ранее подход был неформальным, может возникнуть сопротивление четкому подходу к Управлению Проблемами, особенно в плане документирования и ведения записей. По этой причине сотрудники, участвующие в Управлении Проблемами, должны быть своевременно информированы о разработке и реализации процесса. Глава 6. Управление Конфигурациями
В каждой ИТ-организации имеется информация об ИТ-инфраструктуре. Она чаще всего появляется после реализации крупных проектов, которые обычно завершаются проведением аудита и анализом результатов. Главным в работе с такой информацией является поддержание ее в актуальном состоянии. Процесс Управления Конфигурациями помогает получать достоверную и актуальную информацию об ИТ-инфраструктуре. Важным в этой информации является то, что в нее входят данные не только о конкретных единицах конфигурации (Конфигурационных Единицах[84]
или CI), но и о том, как они связаны друг с другом. Взаимоотношения и взаимосвязи между Конфигурационными Единицами составляют основу для анализа степени воздействия инцидентов, проблем, изменений и т. д. на ИТ-инфраструктуру. Процесс Управления Конфигурациями проверяет, правильно ли регистрируются изменения в ИТ-инфраструктуре, включая взаимоотношения между Конфигурационными Единицами (CI), и ведет мониторинг статуса ИТ-компонентов чтобы гарантировать наличие точной информации о версиях существующих Конфигурационных Единиц (CIs). В случае если Управление Конфигурациями реализовано эффективно, то этот процесс может дать информацию о следующем: - Финансовая информация и политика компании в отношении продуктов - Какие ИТ-компоненты используются в настоящее время по каждой модели (версии) и на протяжении какого времени- - Какие тенденции существуют в разных группах продуктов- - Какова текущая и остаточная стоимость ИТ-компонентов- - Какие ИТ-компоненты нужно выводить из операционной среды и какие требуют модернизации- - Сколько будет стоить замена определенных компонентов- - Какие имеются лицензии и достаточно ли их- - Какие контракты на сопровождение следует пересмотреть- - Какова степень стандартизации инфраструктуры- - Выявление неисправностей и оценка результатов - Какие ИТ-компоненты необходимы для поддержки процесса восстановления в случае чрезвычайной ситуации- - Будет ли работать план восстановления на случай чрезвычайных обстоятельств, если была изменена Конфигурация Инфраструктуры- - Какие ИТ-компоненты будут затронуты при развертывании новых сервисов- - Как оборудование подключено к сети- - Какие программные модули входят в каждый из комплектов программного обеспечения- - Какие ИТ-компоненты затрагиваются изменениями- - Какие Запросы на Изменения (RFC) конкретных ИТ-компонентов находятся на рассмотрении и какие инциденты и проблемы произошли в прошлом и сейчас продолжают оставаться актуальными- - Какие ИТ-компоненты вызывают известные ошибки- - Какие ИТ-компоненты были закуплены у конкретного поставщика в течение определённого периода- - Предоставление услуг и выставление счетов - Какие Конфигурации ИТ-компонентов являются существенными для определенных услуг- - Какие ИТ-компоненты используются в том или ином месте и кем- - Какие стандартные ИТ-компоненты может заказать пользователь и какие из них поддерживаются (каталог продуктов)- По терминологии процесса Управления Конфигурациями ИТ-компоненты и предоставляемые на их основе услуги называются Конфигурационными Единицами (CI). Каждый ИТ-компонент, чье наличие и версия зарегистрированы, является Конфигурационной Единицей. Как видно из рис. 6.1. Конфигурационными Единицами могут быть технические средства, все виды программного обеспечения, активные и пассивные сетевые элементы, серверы, системные блоки, документация, процедуры, услуги и все другие ИТ-компоненты, контролируемые ИТ-организацией. Если Управление Конфигурациями применено к информационным системам, а не только к информационным технологиям, то Конфигурационная База Данных[85]
(CMDB) может хранить и управлять детальной информацией о пользователях, персонале ИТ-организации и бизнес-структурах. Эти Конфигурационные Единицы также попадают под действие процесса Управления Изменениями, например, при найме и увольнении работников.
Документация: •Планы проекта •Планы изменений •Руководства •Документация процесса •Процедуры •Соглашения об Уровне Услуг Перхгональный KOAVibOTep Дисковод Клавиатуре □ Монитор Мини-ЭВМ или мэйнфрэйм Сетевая плата Рис. 6.1. Конфигурационные Единицы Все Конфигурационные Единицы должны быть включены в Конфигурационную Базу Данных (CMDB), которая отслеживает все ИТ-компоненты и взаимоотношения между ними. В самой примитивной форме Конфигурационная База Данных представляет собой набор бумажных форм или электронных таблиц. Разработчики часто используют нечто подобное Конфигурационной Базе Данных для контроля версий всех программных модулей. Некоторые платформы предоставляют такой вид контроля. Конфигурационная База Данных может состоять из нескольких физически раздельных баз данных, которые вместе составляют единое логическое целое. Рекомендуется оптимально интегрировать различные источники Конфигурационных Данных. Не следует путать Конфигурационную Базу Данных со складскими или инвентаризационными базами данных. Такие программы предоставляют только ограниченную информацию о действующем аппаратном и программном обеспечении, сетевых компонентах и компонентах среды. Кроме того, Конфигурационная База Данных (CMDB) демонстрирует, какой должна быть инфраструктура, если все идет по плану (см. также Управление Изменениями), включая документацию. Данные в базе CMDB фактически представляют авторизованную Конфигурацию Инфраструктуры. Список расхождений (дельта) между бухгалтерскими и Конфигурационными Базами Данных является источником ценной информации. Управление Конфигурациями не следует путать с Управлением Активами. - Управление Активами – это бухгалтерский процесс мониторинга амортизации активов, чья закупочная цена превышает определенную величину. Мониторинг ведется путем учета закупочных цен, амортизации, месторасположения активов. Эффективно работающая система Управления Активами может послужить основой для системы Управления Конфигурациями. - Управление Конфигурациями идет дальше, учитывая также информацию о взаимоотношениях между Конфигурационными Единицами и решая задачу стандартизации и авторизации единиц CI. Управление Конфигурациями также контролирует информацию о статусе ИТ-компонентов, их расположении, произведенных в них изменения и т. д. 6.2. Цель процесса
Цель процесса Управления Конфигурациями – содействие в Управлении Значимостью[86]
ИТ-услуг (сочетание требований заказчика, качества и затрат) путем поддержки логической модели ИТ-инфраструктуры и ИТ-услуг и предоставления информации о них другим бизнес-процессам. Это достигается посредством идентификации, мониторинга, контроля и предоставления информации о Конфигурационных Единицах и их версиях. Задачами данного процесса являются: - точная регистрация детальной информации об ИТ-компонентах и услугах, предоставляемых организацией; - предоставление точной информации и документации для поддержки других процессов сервис-менеджмента. Управление Конфигурациями содействует рентабельному предоставлению высококачественных ИТ-услуг с помощью: - Управления ИТ-компонентами – ИТ-компоненты являются крайне важным элементом при предоставлении ИТ-услуг. Каждая услуга включает одну или несколько Конфигурационных Единиц, и процесс Управления Конфигурациями контролирует, что происходит с этими единицами. - Повышения качества коммерческих услуг – процесс Управления Конфигурациями помогает в обработке изменений, выявлении и разрешении проблем и поддержке пользователей. Это приводит к сокращению количества ошибок и, как следствие, к уменьшению расходов. - Эффективного разрешения проблем – Управление Конфигурациями помогает в определении Конфигурационных Единиц, затронутых проблемой, и контролирует модификацию и замену этих элементов. Данный процесс также предоставляет информацию о тенденциях, которая является также входной информацией для Управления Проблемами. - Более быстрой обработки изменений – Управление Конфигурациями помогает в проведении более быстрого и точного анализа степени влияния, поэтому изменения могут быть реализованы быстрее и эффективнее. - Лучшего контроля аппаратного и программного обеспечения – распространение пакетов программ по возможности нужно объединять с установкой (распространением) аппаратного обеспечения и проведением предварительного тестирования. Конфигурационную Базу Данных и Базисные Конфигурации (т. е. мгновенные "фотографии" состояния инфраструктуры) можно использовать для разработки плана тестирования и распространения конкретным группам пользователей. В базе также содержится информация о проверенных версиях программного обеспечения, которые можно использовать при проведении изменений в случае необходимости возврата в исходное состояние. - Улучшенной безопасности – Управление Версиями дает информацию об авторизованных изменениях в Конфигурационных Единицах и использовании различных модификаций программного обеспечения. Такая информация из Конфигурационной Базы Данных также помогает в мониторинге лицензий. - Соблюдения требований закона – незаконные копии будет выявляться при сравнении результатов аудиторской проверки с Конфигурационной Базой Данных. Это может принести дополнительную пользу организации, т. к. незаконные версии могут содержать вирусы, а процесс Управления Конфигурациями может защитить организацию от их проникновения. В некоторых организациях не так легко помешать персоналу использовать незаконное и потенциально зараженное программное обеспечение, тем не менее тот факт, что такие версии могут быть обнаружены с помощью процесса Управления Конфигурациями, Конфигурационной Базы Данных и аудиторских проверок и что по результатам проверок будут приняты дисциплинарные меры, послужат предостережением персоналу. На нарушение правил персонал обычно толкает мысль, что об этом никто не узнает. - Более точного планирования расходов – Конфигурационная База Данных предоставляет информацию о затратах на сопровождение и контракты, лицензии и продукцию с истекшим сроком эксплуатации. - Лучшей поддержки процессов Управления Доступностью и Управления Мощностями – эти процессы в части планирования и анализа услуг зависят от правильной детальной информации о Конфигурациях. - Крепкого надежного фундамента для Управления Непрерывностью ИТ-услуг - Конфигурационная База Данных, если имеется ее резервная копия в надежном месте, может играть важную роль в восстановлении услуг в случае чрезвычайных обстоятельств. База также помогает в определении Конфигурационных Единиц, необходимых для такого восстановления, включая соответствующие процедуры и руководства, если они входят в состав базы. - Определение скрытых затрат — большая часть персонала ведет учетные записи о той части инфраструктуры, за которую они отвечают. Поскольку такая информация может собираться разными людьми и с разными целями, то в ней могут наблюдаться частичные совпадения. Дублирование и противоречивость в данных всегда влекут за собой дополнительные затраты и связаны с риском.
Рис. 6.2. Взаимоотношения между Конфигурационной Базой Данных и другими процессами (источник: OGC) Входом для процесса Управления Конфигурациями является информация об изменениях и информация из процесса Управления Закупками, а выходом – отчеты для других процессов и ИТ-руководства. Есть еще другой выход, когда Управление Конфигурациями предоставляет данные из Конфигурационной Базы Данных другим процессам, необходимые им для выполнения своих задач. Процесс Управления Конфигурациями связан с многими другими процессами. Процессу Управления Инцидентами необходима информация о всей инфраструктуре. При регистрации инцидентов процессу нужен доступ к информации о Конфигурационных Единицах, например, для определения расположения единицы и ее владельца, для уточнения связи этой единицы с проблемой или известной ошибкой, уже имеющей обходное решение, для какого заказчика или услуги единица предназначена и каким Соглашением об Уровне Услуг (SLA) регулируется. Процессу Управления Проблемами нужна информация об инфраструктуре со всеми ее сложными связями и взаимоотношениями. У процесса должны быть возможности для привязки проблем или известных ошибок к Конфигурационным Единицам и для использования информации из Конфигурационной Базы Данных для анализа инцидентов и проблем. Путем сравнения фактической Конфигурации Инфраструктуры с Авторизованной Конфигурацией, хранящейся в базе данных, можно выявить возможные отклонения и дефекты в инфраструктуре. Процесс Управления Изменениями использует Конфигурационную Базу Данных для оценки степени воздействия планируемых изменений. Данный процесс авторизует проведение изменений, и эти изменения должны быть связаны с соответствующими Конфигурационными Единицами. Управление Изменениями несет ответственность за регистрацию Запросов на Изменения и предоставляет важную входную информацию для обновления Конфигурационной Базы Данных. Процесс Управления Релизами дает информацию о планах выпуска релизов и их версиях, например, о плановых датах основных и второстепенных релизов, а также о произведенных изменениях. Перед выполнением изменения процесс запрашивает информацию о Конфигурационной Единице, например, статус CI, ее расположение, исходный код и т. д. Процессу Управления Уровнем Услуг нужна информация о характеристиках услуг и взаимоотношениях между услугами и лежащей в их основе инфраструктурой. Данные из Соглашений об Уровне Услуги в качестве атрибутов могут храниться в Конфигурационной Базе Данных вместе с другой информацией о Конфигурационных Единицах. Данные об Уровне Сервиса (например, "золотой", "серебряный", "бронзовый") записываются для соответствующей сервисной Конфигурационной Единицы или CI для используемого программного или технического компонента. Процессу Управления Финансами необходима информация об использовании услуг, например, у кого имеется в распоряжении PC. Процесс объединяет эту информацию с данными из Соглашений об Уровне Услуг (SLA) для определения цены. Данный процесс также ведет мониторинг инвестиций и стоимости ИТ-компонентов (Управление Активами). Процесс Управления Доступностью использует Конфигурационную Базу Данных для определения Конфигурационных Единиц, задействованных в услуге, для составления плана изменений и для выявления слабых мест, например, с помощью методики CFIA (Component Failure Impact Analysis – анализ влияния сбоев компонентов на предоставление сервиса). Доступность услуги (цепь компонентов инфраструктуры) определяется тем, насколько надежным является самый слабый компонент (звено цепочки). Процесс Управления Конфигурациями предоставляет информацию о составе цепочки, а также о каждом ее звене. Процесс Управления Непрерывностью ИТ-услуг использует стандартные Конфигурации из Конфигурационной Базы Данных (Базисные Конфигурации) для формулирования требований к восстановлению услуг в случае возникновения чрезвычайных обстоятельств и проверяет наличие этих Конфигураций на запасной территории. Процесс Управления Мощностями использует данные из Конфигурационной Базы Данных для оптимизации ИТ-инфраструктуры, распределения рабочей нагрузки и разработки плана мощностей. Хотя процесс Управления Конфигурациями, как и другие процессы, представляет собой логическую последовательность действий, в данном процессе они не всегда выполняются строго последовательно. Виды деятельности при Управлении Конфигурациями имеют тенденцию выполняться параллельно. Приведенная ниже последовательность, прежде всего, отражает очередность действий при разработке процесса, а также при обработке и реализации новых информационных требований. - Планирование: определяются стратегия, политика и задачи процесса, анализируется имеющаяся информация, определяются инструментальные средства и ресурсы, создаются интерфейсы с другими процессами, проектами, поставщиками и т. д. - Идентификация: формируется процесс поддержки базы данных в актуальном состоянии. В этот этап входит разработка модели данник для регистрации всех ИТ-компонентов инфраструктуры, взаимоотношений между ними и информации о владельце этих компонентов или лица, ответственного за них, статусе единиц, а также об имеющейся документации. Также должны быть разработаны процедуры создания новых Конфигурационных Единиц и для изменения уже существующих. Поскольку потребности в информации постоянно меняются, определение состава данных о Конфигурации также меняется. - Контроль: контроль обеспечивает актуальное состояние Конфигурационной Базы Данных путем принятия, регистрации и мониторинга авторизованных и идентифицированных Конфигурационных Единиц. Наличие контроля гарантирует, что ни одна Конфигурационная Единица не будет добавлена, изменена, заменена или удалена без соответствующего документа, например, утвержденного Запроса на Изменение или скорректированной спецификации. - Мониторинг статуса: хранение текущей информации и истории статуса Конфигурационной Единицы на протяжении ее жизненного цикла. С помощью мониторинга статуса можно отследить, как меняется статус единицы, например "в разработке", "в тестировании", "в наличии", "в использовании", - "выведено из рабочей среды". - Верификация: верификация Конфигурационной Базы Данных путем аудита ИТ-инфраструктуры на наличие в ней зарегистрированных Конфигурационных Единиц и правильности регистрационных записей. - Отчетность: предоставление информации в другие процессы и подготовка отчетов об использовании Конфигурационных Единиц, тенденциях и т. д. Ниже дается подробное описание этих действий. Задачи процесса Управления Конфигурациями, сфера его действия, а также приоритеты должны определяться в рамках Сервис-менеджмента и обязаны соответствовать бизнес-целям организации. Соответствующие этапы в реализации Управления Конфигурациями выходят за рамки данной книги. Идентификация связана с определением и поддержкой соглашений о присвоении имен и нумерации версий физических компонентов инфраструктуры, взаимоотношений между ними и атрибутов. Базисные Конфигурации Аппаратного Обеспечения, используемого в настоящий момент и в будущем, описываются в форме специальных групп Конфигурационных Единиц (кластеров CI). Общий вопрос, на который должна дать ответ идентификация ИТ-компонентов состоит в следующем: Какие услуги и связанные с ними компоненты ИТ-инфраструктуры должны находиться под контролем Сервис-менеджмента и какая информация необходима для этого- При разработке системы идентификации должны быть приняты решения относительно охвата (границ)[87]
процесса и уровня детализации регистрируемой информации. Для каждого параметра (характеристики) следует определить владельца или заинтересованное лицо[88]
. Чем больше параметров регистрируется, тем больше усилий потребуется на обновление этой информации. Общий вопрос "Что же регистрировать-" может быть сведен к перечню конкретных вопросов для определения требуемой информации, например: - Какие ресурсы имеются для сбора и обновления информации- - Насколько зрелыми являются наши административные и материально-технические (логистические) процессы- - На каких уровнях организация выполняет инсталляцию, замену, разработку и/или распространение компонентов отдельно от основного компонента- - Какие виды деятельности, выполняемые сторонними организациями, должны измеряться и контролироваться- - Какие компоненты могут повлиять на услуги в случае сбоя и какая нужна информация для диагностики этих сбоев- - Для каких компонентов следует регистрировать статус и его предысторию- - Какие компоненты используются в организации в различных версиях или вариантах- - Изменения в каких компонентах могут повлиять на возможности и доступность услуг- - Какие компоненты являются дорогостоящими и их следует защищать от кражи или утери- - Какова настоящая и будущая информационная потребность у других процессов- - Для каких компонентов требуется такая информация, как серийный номер, дата покупки и поставщик, и какая информация необходима для бухгалтерии- - Какие требования вытекают из условий, закрепленных в Соглашениях об Уровне Услуг- - Какая информация необходима для выставления счетов заказчикам- - Насколько реальны наши стремления, не нужна ли корректировка- Ответы на эти вопросы дают представление об объеме работ, которые необходимо выполнить. Следует принять решение об охвате (ширине, границах) CMDB и уровне ее детализации (глубине). Понятие детализации включает в себя: количество уровней в базе данных, взаимоотношения, подлежащие мониторингу, соглашения о присвоении имен и атрибуты. Все они будут рассмотрены ниже. Охват (сфера действия, границы)
[89]
При создании Конфигурационной Базы Данных и обновлении модели данных следует определиться, какая часть ИТ-инфраструктуры будет находиться под контролем процесса Управления Конфигурациями. Например, следует ли включать в сферу действия данного процесса такие компоненты, как "электронные органайзеры" (PDA), сетевые копировальные устройства, факсы, клавиатуры и ИТ-персонал, или же они должны находиться за пределами действия процесса- Границы, определенные для процесса Управления Конфигурациями, влияют на границы, в которых, например, процесс Управления Проблемами выполняет диагностирование, на анализ степени воздействия, проводимый процессом Управления Изменениями, планирование, выполняемое процессом Управления Доступностью и т. д. Кроме того, работая над границами процесса можно произвести анализ вклада ИТ-услуг в конечную деятельность заказчика или степень воздействия на нее, а также рассмотреть соглашения с пользователями об уровне поддержке и услугах. Сферу действия процесса можно разделить на области, каждая со своими требованиями и подходом к проектированию. Примерами таких областей могут стать настольные рабочие места, системы передачи данных, файловые сервисы, сервисы печати и прикладного ПО, центральная процессинговая система, базы данных, телефонные услуги. Для разработки каждой области может быть инициирован отдельный проект в соответствующей управленческой среде. Границы Конфигурационной Базы Данных могут включать аппаратное и программное обеспечение, а также документацию, например, Соглашения об Уровне Услуг (SLAs), процедуры, руководства, технические спецификации, организационные схемы, персонал и планы проектов. Как и другие Конфигурационные Единицы, эти документы физически могут находиться в разных местах, но информация о них находится в базе данных с номерами версий, датами публикаций, именами авторов и т. д. В этом случае процессы Управления Конфигурациями и Управления Изменениями могут контролировать эти характеристики документов. На рис. 6.3 показаны взаимоотношения между услугами и компонентами Конфигурационной Базы Данных. Отслеживание этих взаимоотношений облегчает определение степени воздействия инцидентов на услуги. Это также позволяет создавать отчет обо всех компонентах, вовлеченных в предоставление сервиса. Такая информация в дальнейшем может быть использована для улучшения услуг. У такой "сервисной" Конфигурационной Единицы могут быть взаимоотношения с другими единицами, такие как договоренности с заказчиком в форме Соглашения об Уровне Услуг. В приведенном примере услуга "В" полностью выходит за границы базы данных. Из рисунка видно, что не все Конфигурационные Единицы, участвующие в услуге "А", входят в сферу действия Конфигурационной Базы Данных (например, находятся в рассматриваемой организации), это означает, что услуга "А" не может полноценно поддерживаться.
Рис. 6.3. Охват Конфигурационной Базы Данных (источник: OGC) После определения областей, включенных в сферу действия процесса, возможно определить этапы жизненного цикла Конфигурационных Единиц, которые будут содержаться в CMDB. Будут ли единицы со статусом "в разработке" или "заказана" включены в базу данных или же их включат в CMDB только после того, как они будут введены в работу- Преимущество включения в базу данных продуктов, находящихся на стадии разработки, состоит в том, что в этом случае их спецификации уже нельзя будет менять без получения одобрения, и их передача в рабочую среду будет происходить согласованно. От этого выбора будет зависеть мониторинг статуса CI в рамках процесса Управления Конфигурациями, к тому же это позволит расширить диапазон контроля жизненного цикла продукта в рамках этого процесса. Уровень Детализации CMDB
Определение Уровня Детализации для каждого типа Конфигурационных Единиц является важным этапом разработки процесса Управления Конфигурациями. Здесь нет универсальных решений. На этом этапе анализируется информация о Конфигурационных Единицах. Для определения Уровня Детализации составляется схема взаимоотношений между задействованными Конфигурационными Единицами и выбирается требуемая глубина детализации CMDB. Кроме того, определяются имена и атрибуты для Конфигурационных Единиц. При определении глубины Конфигурационной Базы Данных и взаимоотношений между Конфигурационными Единицами, отражаемыми в CMDB, нужно добиться сбалансированности требований к CMDB – с одной стороны, и загруженности персонала и имеющихся ресурсов – с другой. Количество взаимоотношений растет экспоненциально количеству уровней. Взаимоотношения между Конфигурационными Единицами
Информация о взаимоотношениях между Конфигурационными Единицами является очень полезной для диагностики ошибок и прогнозирования доступности услуг. Можно определить много разных типов взаимоотношений на логическом и физическом уровнях. - Взаимоотношения на физическом уровне: - Является частью: это взаимоотношения типа "parent/child" ("родитель/ребенок"), например, дисковод является частью PC, а программный модуль – частью программы. - Подключена к: например, PC подсоединен к сегменту сети. - Требуется для: например, технические средства требуются для работы приложения. - Взаимоотношения на логическом уровне: - Является копией: что-то является копией стандартного модуля, Базисной Конфигурации или программы. - Связано с: процедурой, руководством и документацией, Соглашением об Уровне Услуг или группой заказчиков. - Используется: например, Конфигурационная Единица, участвующая в предоставлении услуги, или программный модуль, к которому обращаются несколько программ. Глубина CMDB
При определении Уровней Конфигурационных Единиц создается иерархия компонентов и элементов. Выбираются родительские Конфигурационные Единицы и определяется количество уровней, необходимых для их детализации. На самом высоком уровне находится сама ИТ-инфраструктура. Самым низким уровнем является наиболее детальный уровень, на котором необходимо осуществлять контроль. Включение Конфигурационных Единиц в Конфигурационную Базу Данных будет целесообразным только в том случае, если информация об этих CI будет полезна для других процессов ITIL. Определяя уровни и глубину Конфигурационной Базы Данных, следует помнить, что изменение в любой Конфигурационной Единице, зарегистрированной в CMDB, должно пройти через формальный процесс Управления Изменениями, прежде чем оно будет произведено. Поэтому регистрируя такой компонент как компьютерная мышь в Конфигурационной Базе Данных, создается ситуация, при которой любой Запрос на новую мышь уже не будет проходить как Запрос на Обслуживание[90]
, а должен будет проводиться через процесс Управления Изменениями в форме Запроса на Изменение (RFC). Это показательный пример для организаций, которые чрезмерно увлекаются детализацией. При определении структуры Конфигурационной Базы Данных руководствуются следующими соображениями: - Чем больше уровней в базе данных, тем больше информации надо обрабатывать. Это ведет к увеличению рабочей нагрузки и созданию более сложной CMDB. - Чем меньше уровней, тем слабее контроль и хранится меньше информации об инфраструктуре. Если степень детализации CMDB слишком мала, то становится невозможным эффективный мониторинг изменений, происходящих в компонентах нижнего уровня. В этом случае любое изменение в компонентах родительской Конфигурационной Единицы приведет к созданию варианта этой единицы[91]
. Например, PC с двумя видами жесткого диска будет проходить как Вариант "А" и Вариант "В". Если в дочернем компоненте много изменений, их нумерация становится сложной и трудной для сопровождения. Однако, если имеются уровни, расположенные ниже, то варианты можно поддерживать на соответствующем уровне. Для дочерних компонентов также можно регистрировать больше атрибутов и связывать с ними известные ошибки. Кроме того, при выполнении диагностики можно ставить такие вопросы, как: "Какой драйвер нужен для этого типа технических средств-", "К какому сегменту подсоединена сетевая плата-" и "Какая программа использует эту библиотеку-". Соглашения о присвоении имен
[92]
У каждой Конфигурационной Единицы должно быть уникальное имя, которое отличает его от других единиц. Самым элементарным вариантом является простая система присвоения номеров с возможным делением на диапазоны для каждой области. Для вновь созданной Конфигурационной Единицы генерируется новый номер. Имена, по возможности, должны иметь смысловое значение для облегчения контактов с пользователями. Соглашения о присвоении имен также можно использовать для физической маркировки Конфигурационных Единиц, для упрощения их идентификации при инвентаризации (аудите), в процессе сопровождения и регистрации инцидентов. Некоторые из предложенных библиотекой ITIL правил присвоения имен: - Метки на аппаратных средствах должны быть легко различимыми и легкими в чтении для пользователей, они должны прочно фиксироваться на поверхности. По договоренности со сторонним поставщиком услуг, в договорах о поддержке могут существовать ссылки на эти метки. Пользователи также должны указывать метки при сообщении об инциденте. - Контролируемые документы, такие как Соглашения об Уровне Услуг (SLA), процедуры и организационные схемы должны маркироваться с указанием номера Конфигурационной Единицы, номера версии и даты выпуска версии. - Копии программного обеспечения должны храниться в Библиотеке эталонного программного обеспечения[93]
(DSL), см. главу "Управление Релизами". Все компоненты программного обеспечения должны иметь номер CI, а инсталлированное ПО еще и номер версии и номер копии. Атрибуты
Помимо структуры Уровней Конфигурационных Единиц, взаимоотношений между ними и соглашений о присвоении имен, детальная проработка модели CMDB также включает в себя описание атрибутов. Атрибуты используются для хранения информации, имеющей отношение к Конфигурационной Единице. При формировании CMDB можно использовать приведенные ниже атрибуты. АТРИБУТ
ОПИСАНИЕ
Номер/метка Конфигурационной Единицы или штриховой код Уникальный идентификатор Конфигурационной Единицы. Часто это номер, автоматически присваиваемый базой данных. Хотя не все Конфигурационные Единицы имеют физические метки, у всех есть уникальный номер Номер лицензии или серийный номер Идентификационный номер поставщика в виде серийного номера или номера лицензии Номер инвентаризационной системы Инструментальные средства инвентаризации (аудита) часто используют свои собственные идентификаторы, которые в разных областях инфраструктуры могут быть разными. Данный атрибут обеспечивает связь с этой средой Номер модели/ идентификационный номер Каталога Уникальный идентификатор, используемый в Каталоге Поставщика. У каждой версии модели свой номер, например, PAT-NL-C366-4000-T Наименование модели Полное наименование модели, в которое часто входит идентификатор версии, например, PIIMMX400MHZ Изготовитель Изготовитель Конфигурационной Единицы Категория Классификация Конфигурационной Единицы (например, технические средства, программное обеспечение, документация и т. д.) Тип Описание типа Конфигурационной Единицы, предоставляет детальную информацию о категории, например, Аппаратная Конфигурация, пакет программ или программный модуль Гарантийный срок Срок действия гарантии Номер версии Номер версии Конфигурационной Единицы Расположение месторасположение Конфигурационной Единицы, например, библиотека или носитель, на котором находится программное обеспечение, или территория/комната, где находится Конфигурационная Единица Владелец Имя владельца или лица, ответственного за Конфигурационную Единицу Дата начала ответственности Дата, когда вышеуказанное лицо стало ответственным за Конфигурационную Единицу Источник/поставщик Источник Конфигурационной Единицы, например, собственная разработка, закуплена у поставщика "X" и т. д. Лицензия Номер лицензии и ссылка на лицензионное соглашение Дата поставки Дата поставки Конфигурационной Единицы в организацию Дата приемки Дата приемки Конфигурационной Единицы в операционную среду Статус (текущий) Текущее состояние Конфигурационной Единицы, например, "в тестировании", "в работе", "выведено из операционной среды" Статус (запланированный) Следующий планируемый статус Конфигурационной Единицы с указанием даты и требуемых действий Стоимость Стоимость приобретения Конфигурационной Единицы
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||