Библиотеки инфраструктуры информационных технологий или ITIL (the IT Infrustructure Library)

Д.А. Скрипник Электронная книга (fb2 - 2.7 Мб, txt - 509.6 Кб, html - 3.5 Мб, epub - 3.7 Мб) Курс рассматривает основные аспекты шести публикаций Библиотеки инфраструктуры информационных технологий или ITIL (the IT Infrustructure Library). Курс посвящен Управлению услугами и основан на шести публикациях ITIL. В лекциях даются ключевые понятия области, и рассматривается жизненный цикл услуг от этапа Построения стратегии до Непрерывного улучшения услуг. В рамках каждого этапа дается описание основных процессов, их целей, входов/выходов и ключевых показателей эффективности. http://www.intuit.ru/goods_store/ebooks/8585 Оглавление Введение в ITIL ............................................................................................................................................. 3 1.1. Введение в ITIL.Основные термины. .............................................................................................. 3 1.2. Жизненный цикл услуги ................................................................................................................... 9 Построение стратегии как этап жизненного цикла услуг ......................................................................13 2.1. Построение стратегии как этап жизненного цикла услуг ...........................................................13 2.2. Функции и процессы в жизненном цикле услуги ........................................................................14 2.3. Факторы, влияющие на ценность услуги ......................................................................................16 2.4. Типы поставщиков услуг ................................................................................................................17 2.5. Фундаментальные основы планирования ...................................................................................21 2.6. Четыре "П" Построения стратегии ................................................................................................24 Процессы в рамках Построения стратегии. Портфель услуг и Каталог услуг .......................................27 3.1. Определение возможностей и ценности услуги .........................................................................27 3.2. Формирование Портфеля услуг.....................................................................................................31 3.3. Управление финансами .................................................................................................................36 3.4. Возврат инвестиций .......................................................................................................................42 Проектирование услуг как этап жизненного цикла услуг ......................................................................46 4.1. Проектирование услуг как этап жизненного цикла.....................................................................46 4.2. Основные аспекты проектирования .............................................................................................52 4.3. Дальнейшие действия в рамках Проектирования услуг .............................................................60 4.4. Модели для проектирования и предоставления услуг...............................................................61 Процессы в рамках этапа Проектирования: Управление Каталогом услуг, мощностями и доступностью .............................................................................................................................................65 5.1. Управление Каталогом услуг .........................................................................................................65 5.2. Управление уровнем услуг ............................................................................................................68 5.3. Управление мощностями ..............................................................................................................72 5.4. Управление доступностью .............................................................................................................78 Управление непрерывностью услуг и информационной безопасностью в рамках этапа Проектирования. Управление поставщиками ........................................................................................84 6.1. Управление непрерывностью услуг ..............................................................................................84 6.2. Управление информационной безопасностью ...........................................................................93 6.3. Управление поставщиками ...........................................................................................................99 Внедрение как этап жизненного цикла услуг .......................................................................................106 7.1. Внедрение как этап жизненного цикла услуг ............................................................................106 7.2. Основные принципы этапа Внедрения ......................................................................................110 Планирование Внедрения. Управление изменениями, активами и конфигурациями в рамках Внедрения ................................................................................................................................................119 8.1. Планирование и поддержка Внедрения ....................................................................................120 8.2. Управление изменениями ...........................................................................................................122 8.3. Управление активами и конфигурациями .................................................................................129 Управление релизами и развертыванием в рамках Внедрения услуг ...............................................135 Подтверждение, тестирование и оценка услуг на этапе Внедрения. Управление знаниями..........146 10.1. Подтверждение и тестирование услуг .....................................................................................146 10.2. Оценка .........................................................................................................................................153 10.3 Управление знаниями .................................................................................................................156 Эксплуатация услуг как этап жизненного цикла услуг .........................................................................160 Управление событиями и инцидентами в рамках Эксплуатации услуг .............................................171 12.1. Управление событиями...................................................................................................... 171 12.2. Управление инцидентами .........................................................................................................177 Управление запросами, доступом и проблемами в рамках Эксплуатации услуг .............................184 13.1. Управление запросами на обслуживание................................................................................184 13.2. Управление проблемами...........................................................................................................185 13.3 Управление доступом .................................................................................................................191 13.4. Взаимосвязь процессов Эксплуатации с другими этапами жизненного цикла ...................193 Непрерывное улучшение услуг как этап жизненного цикла услуг .....................................................195 14.1. Непрерывное улучшение услуг как этап жизненного цикла услуг ........................................195 14.2. Основные принципы непрерывного улучшения услуг ...........................................................201 Процессы в рамках Непрерывного улучшения услуг ...........................................................................205 15.1. 7-шаговый процесс улучшения........................................................................................205 15.2. Формирование отчетности ........................................................................................................210 15.3. Измерение услуг .........................................................................................................................211 15.4. ROI для Непрерывного улучшения услуг ..................................................................................216 15.5. Вопросы бизнеса к CSI ................................................................................................................218 15.6. Управление уровнем услуг (SLM) ..............................................................................................220 Заключение и словарь ............................................................................................................................220 Лекция 1: Введение в ITIL Аннотация: Что такое ITIL, назначение ITIL, состав ITIL, ключевые термины в контексте ITIL, история возникновения. Ключевые слова: Интернет, локальные сети, технология клиентсервер, информация, OGC, ITIL, information, management, forum, объединение, service, examination, board, целый, покупатель, группа, определение, бизнес-процесс, CASE, слово, запоминающее устройство, онлайн, путь, опыт, warranty, SLA, представление, полезность, мера, оптимизация, мен еджмент, ITSM, изготовитель, продажа, mission, SMART, relevant, Achievable , policy, работ, critical, C SF, бизнес-процессы, KPI, метрика, подразделения, цикла, жизненный цикл, очередь, портфель, pipeline, retire, производительность, дизайн, принятия решений, utility computing, электронная коммерция, бизнесмодель, пользователь, провайдер, аналогия, диаграмма, SLP, SDP, поддержка 1.1. Введение в ITIL.Основные термины. Конец XX века ознаменовал собой переход от индустриального общества к информационному. Уже в середине 80-х годов прошлого столетия IT-индустрия стала стремительно развиваться: появились персональные компьютеры, Интернет, локальные сети, технология клиент-сервер и т.п. Информация, средства ее обработки и управления стали основными стратегическими ресурсами любой организации, а достижение бизнес целей стало напрямую зависеть от IT-области. Процесс информатизации вначале носил достаточно стихийный характер: быстро появлялись новые технологии, услуги и приложения. Другими словами IT-область была ориентирована, прежде всего, на "новизну" и "количество" IT-услуг, то есть на разработку. После первичного насыщения рынка его участники осознали необходимость обеспечения качества IT-услуг. В настоящее время обеспечение качества IT-услуг является ключом к эффективному анализу, обработке и распространению информации, то есть к успешной деятельности организации в целом. В 1980-х годах британское правительство поручило Центральному агентству по вычислительной технике и коммуникациям (CCTA) разработать общие принципы эффективного использования ITсервисов в Великобритании. Так появился первый документ, объединяющий в себе лучшие практики в управлении IT-услугами. Основной его особенностью стала разработка единого подхода, не зависящего от поставщика услуг. В конце 1980-х-начале 1990 вышла серия книг о том, как управлять IT-услугами и о взаимодействии IT-области с пользователями этих услуг. Эта библиотека книг и была названа Библиотекой инфраструктуры информационных технологий или ITIL(the IT Infrastructure Library). В дальнейшем CCTA было объединено с Государственной торговой палатой или OGC, которая в настоящее время и является владельцем библиотеки ITIL. ITIL, по сути, представляет собой набор публикаций, содержащих рекомендации по предоставлению качественных услуг, а также процессов и компонентов, необходимых для их поддержки. Основная цель ITIL - продвижение современных знаний и обмен опытом в области. Основная особенность ITIL - организация Управления услугами в виде совокупности процессов. В 1991 году после того, как IT-сообщество заинтересовалось ITIL, был создан форум IT Information Management Forum (ITIMF). Его целью стало объединение специалистов IT-области, обмен идеями и опытом. В дальнейшем название сменилось на IT ServiceManagement Forum (ITSMF). Сейчас этот форум объединяет в себе множество специалистов IT-области, и количество пользователей форума по всему миру растет ежедневно. Следующая серия книг - ITIL v2 - появлялась с середины 1990 годов по 2004 год. Если первая версия содержала более 60 книг, то вторая - всего 9, а в третьей - 5. Основной целью второй версии стало описание процесса эффективной передачи услуги потребителю и уменьшение разрыва между IT-областью и бизнесом. В 2004 году было начато второе обновление ITIL ввиду того, что появилось много новых технологий и принципиальных изменений в IT-области. Результатом стала ITILv3, о которой и пойдет речь в данном курсе. В настоящее время ITIL представляет собой наиболее известную базу знаний в области Управления услугами во всем мире и отражает фундаментальные основы ведущих мировых практик в IT-области. В Европе существуют два центра сертификации по ITIL- EXIN (Голландский Экзаменационный Институт) и ISEB (The Information Systems Examination Board - подразделение Британского Компьютерного Общества). Внедрением процессов ITIL и обучением занимается целый ряд компаний-консультантов. В России "передовиками" являются HewlettPackard Consulting, "Ай-Теко", IT-Expert. ITIL рассматривает Управление услугами в контексте взаимодействия "поставщик услуг - заказчик услуг". Заказчик (Customer) - это покупатель товаров или услуг. Заказчик для поставщика IT-услуг - это человек (группа людей), который заключает соглашения с поставщиком на предоставление ITуслуг и отвечает за то, чтобы предоставленные услуги были оплачены. Поставщик услуг (Service provider) - это организация, поставляющая услуги одному или нескольким внутренним или внешним заказчикам. Выделяют также пользователей услуг. Пользователь - это сотрудник организации, использующий IT-услугу для выполнения повседневной работы. Центральным и ключевым термином ITIL является сервис (service), который в русскоязычной литературе часто называют услугой. Приведем определение из Глоссария ITIL v3: IT-услуга (сервис) - способ предоставления ценности заказчикам через содействие им в получении результатов на выходе, которых заказчики хотят достичь без владения специфическими затратами и рисками [1]. Приведем другое определение IT-услуги. IT-услуга - одна или более техническая или профессиональная возможность, которая делает возможным бизнес-процесс. В дальнейшем "ITуслугу" будем называть "услугой", а термины "услуга" и "сервис" считать эквивалентными. Услуга обладает следующими характеристиками: • удовлетворяет одну и более потребностей заказчика; • поддерживает бизнес-цели заказчика; • воспринимается заказчиком как единое целое и продукт, готовый к использованию. Следует отметить, что вся литература ITIL представлена на английском языке. Как следствие, некоторые термины не имеют аналогов на русском (например, business case) или могут переводиться сразу несколькими словами (как в случае сервис-услуга). В определении сервиса мы видим слово ценность - в оригинале "value". Здесь имеется в виду потенциальная выгода для Заказчика от использования IT-услуги (например, экономия времени, денег и других ресурсов). Рассмотрим подробнее основные понятия в определении сервиса. Результаты на выходе (outcomes) - то, что получает заказчик в конечном итоге. Необходимо понимать, что на практике они отличаются от того, что хочет получить заказчик изначально, ввиду наличия определенных ограничивающих факторов. Упрощая назначение услуг, можно сказать, что они помогают улучшить результаты на выходе путем увеличения производительности и уменьшения существующих ограничений. Результатом применения услуг является увеличение вероятности получения желаемых результатов на выходе. Модели услуг, которые предлагает ITIL, помогают управлять сложностями, затратами, гибкостью и многообразием в IT-области. Каждая модель имеет множество вариантов использования в зависимости от конкретного случая, что делает идею ее применения универсальной, гибкой и эффективной. Модель IT-услуги можно рассмотреть на примере системы хранения информации. Система предназначена для хранения, упорядочивания и защиты информации в контексте некоторой работы или деятельности. Если поставщик предоставляет заказчику не просто запоминающее устройство, а услугу хранения информации, он должен ответить на вопросы "что хранить" и " как хранить" (рис. 1.1). При этом принципиальную важность имеют разграничение обязанностей и ответственности между поставщиком и заказчиком. Рис. 1.1. Схема системы хранения информации Заказчики хотят получить желаемые результаты, но, по различным причинам, не хотят сопутствующих ответственности, расходов и рисков. Например, некая организация хочет иметь защищенную систему хранения в несколько терабайт для поддержки торговли онлайн. Для того чтобы создать такую систему с "нуля", упомянутая организация должна была бы проделать долгий путьот понимания того, как это сделать, до покупки оборудования и найма квалифицированного персонала. Всё это стоит больших денег и отнимает много времени. Гораздо проще в данном случае воспользоваться услугами поставщика, который уже владеет большой системой хранения и имеет соответствующие опыт и возможности. Это будет предоставлением услуги защищенного хранения информации. В определении услуги мы сталкиваемся также с понятием ценность услуги (value). Она измеряется в контексте двух понятий: • Полезность услуги (Service Utility)- то, что получает заказчик в результате использования услуги; • Гарантия качества услуги(Service Warranty) - то, как поставщик предоставляет услугу в терминах доступности, производительности, непрерывности и безопасности. Приведем определения из Глоссария ITILv3: Полезность - функциональность, предлагаемая продуктом или сервисом для обеспечения определённых потребностей. Зачастую определяется как "что делает продукт/сервис". Полезность услуги - функциональность IT-услуги с точки зрения заказчика. Гарантия - обещание или гарантия того, что продукт или услуга будет соответствовать согласованным требованиям. Гарантия качества услуги - уверенность в том, что IT-сервис будет соответствовать согласованным требованиям. Может быть в виде формального соглашения, такого как SLA или договор, либо как маркетинговое сообщение или представление торговой марки[1]. Другими словами, полезность - то, что заказчик получает, гарантия качества - то, как он это получает. На рис. 1.2 представлена упрощенная схема формирования ценности услуги. Рис. 1.2. Схема формирования ценности услуги Заказчик, приобретая услугу, хочет получить результат от ее использования, то есть извлечь ценность. Полезность достигается одним из следующих способов: 1. обеспечение требуемой заказчиком производительности; 2. устранение или снижение ограничений. Производительность (Performance) - мера того, что достигнуто или выработано системой, человеком, командой, процессом, или ИТ-услугой [1]. Под производительностью здесь понимается возможность для заказчика делать больше за более короткое время, с меньшими затратами или с потреблением меньших ресурсов. Другими словами, некая оптимизация, которая позволит заказчику решить задачу за меньшее время и деньги. Ограничение - это запрет или невозможность выполнения каких-то действий. Гарантия складывается из четырех основных аспектов: • доступности • мощности • безопасности • непрерывности Понятно, что измерить гарантию качества услуги проще, чем ее полезность для бизнеса. Когда человек нажимает кнопку, он ждет, что включится свет. К сожалению, с IT-услугами не всё так просто. Результат использования IT-услуги зависит не только от свойств самой услуги, но и от управления этой услугой - здесь и появляется термин service management или управление услугой. Управление IT-услугами (сервисами) - это совокупность специализированных организационных возможностей для предоставления ценности заказчикам в форме услуг[1]. Под "специализированными возможностями" понимаются процессы, методы, функции и роли, которые может использовать поставщик для предоставления услуги заказчику. В России достаточно редко применяют термин управление IT-услугами, предпочитая ему сервис-менеджмент. Для обозначения управления IT-сервисами используется также аббревиатура ITSM (IT Service Management). В ходе курса мы будем использовать термины "Управление услугами", "сервис-менеджмент" и ITSM как тождественные. Предоставление услуг охватывает вопросы менеджмента IT-инфраструктур, включая обслуживание и сопровождение. Перед покупкой любого продукта в магазине мы обычно оцениваем его качество по внешнему виду, пригодности и надежности. В магазине у покупателя немного возможностей повлиять на качество продукта из-за того, что он уже произведен на фабрике. Путем тщательного контроля производства изготовитель будет стараться поставлять продукцию с одинаковым уровнем качества. В этом примере изготовление, продажа и потребление выступают отдельными друг от друга этапами[3]. В IT-области всё обстоит несколько иначе, так как совокупное качество услуги фактически определяется в процессе ее эксплуатации, и его нельзя однозначно определить заранее. Качество - совокупность характеристик объекта, относящихся к его способности удовлетворить установленные и предполагаемые потребности [4]. Организация может купить очень дорогую IT-услугу, но если поставщик не может обеспечить качественное и ответственное управление - эта покупка станет бессмысленной. Удовлетворенность заказчика во многом зависит от того, насколько хорошо были согласованы параметры услуги предварительно с поставщиком услуг. Поставщик должен помнить о необходимости обеспечения постоянного качества. То есть предоставляемая услуга должна быть стабильной во времени. Таким образом, основной целью сервис-менеджмента в контексте ITIL является предоставление заказчикам надежных, стабильных IT-услуг, которые полностью удовлетворят их потребности в заданной области. Еще одним ключевым термином в ITIL является организация. Заказчики IT-услуг и поставщики ITуслуг рассматриваются в форме организации. Организация - это определенная форма сотрудничества людей. Перед любой организацией стоит вопрос: в чем цель объединения в организацию? Такой корпоративной целью (vision) может быть, например, желание заработать деньги, продавая персональные компьютеры или предоставляя услуги доступа в Интернет. Для того чтобы организация стала привлекательной для всех заинтересованных сторон (заказчиков, инвесторов, сотрудников компании и т. д.), нужно уметь рассказать, какие преимущества они будут иметь от сотрудничества с конкретной организацией. Для того чтобы сообщить всем свою корпоративную цель, компания может представить ее в виде тезиса о своей миссии (mission). Рис. 1.3. Структура формирования корпоративной цели организации Миссия - это короткое и четкое описание задач, стоящих перед организацией, и идеалов, в которые она верит. Стратегические задачи (objectives) - это более подробное описание того, что хочет достичь организация в долгосрочной перспективе. Хорошо сформулированные стратегические задачи должны обладать пятью основными свойствами (соответствовать принципу SMART): быть конкретными (Specific), поддаваться измерению (Measurable), быть уместными и соответствующими ситуации (Relevant), быть реалистичными (Achievable ) и иметь четкие временные границы (Timebound). Политика организации (policy) - это совокупность всех решений и мер, принятых организацией для постановки стратегических задач и их достижения. При разработке своей политики организация определяет приоритеты стоящих перед ней стратегических задач и пути их достижения. Безусловно, в зависимости от обстоятельств, приоритеты могут со временем меняться. Чем лучше разъяснена политика организации всем участвующим сторонам, тем меньше возникает проблем при объяснении сотрудникам, как им выполнять работу. В отличие от подробных процедур, эти правила могут быть использованы персоналом организации в качестве руководящих указаний. Четко сформулированная политика (правила) компании способствуют гибкости структуры организации, поскольку все уровни в такой компании могут быстро реагировать на изменение ситуации [3]. Реализация политики в виде конкретных видов деятельности требует разработки стратегии. Стратегия разрабатывается на определенные периоды и состоит из нескольких этапов. Важным является возможность контроля выполнения поставленных задач в ходе исполнения запланированных работ. Другими словами, необходимо измерять, в какой степени организация или процессы близки к достижению своих стратегических целей. Для этого имеются различные методы. Одним из наиболее известных в бизнесе методов является Карта Сбалансированных Оценок (Balanced Score Card - BSC). Согласно данному методу, на основе стратегических целей организации или целей процесса определяются критические факторы успеха (Critical Success Factor - CSF). Критические факторы успеха (Critical Success Factors или CSFs) - факторы, которые обязательно должны реализовываться для успешности проекта, процесса, плана или услуги. Такие факторы формулируются для нескольких наиболее важных сфер интересов компании, называемых перспективами (проекциями) организации: заказчики/рынок, бизнес-процессы, персонал/инновации и финансы. Для измерения того, насколько успешно реализованы CSFs используется KPI. Ключевой показатель производительности (Key Performance Indicator или KPI) метрика, которая используется для управления процессом, услугой или деятельностью[1]. Измерить можно множество показателей эффективности, но только особо важные являются KPI. Например, фактор "защита услуги во время реализации изменений" может быть измерен таким KPI как "уменьшение количества неуспешных изменений в процентах", "процентное уменьшение количества изменений, приведших к возникновению инцидентов" и т.д. Под воздействием различных обстоятельств и результатов измерений эффективности в контрольных точках, стратегические задачи, миссии и корпоративные цели могут претерпевать существенные изменения. При этом стратегические задачи IT-подразделения или поставщиков услуг должны также изменяться в соответствии с требованиями и целями бизнеса. 1.2. Жизненный цикл услуги Основу ITILv3 составляют следующие шесть публикаций, которые часто называют ядром: 1. Введение в ITIL 2. Стратегия услуги (Service Strategy) 3. Проектирование услуги (Service Design) 4. Преобразование услуги (Service Transition) 5. Эксплуатация услуги (Service Operation) 6. Непрерывное улучшение услуги (Continual Service Improvement). Пять книг соответствуют этапам жизненного цикла услуги (за исключением "Введения в ITIL"): от первичного анализа требований бизнеса на этапах построения стратегии и проектирования до улучшения услуги в процессе эксплуатации. Жизненный цикл услуги представлен на рис. 1.4. Рис. 1.4. Жизненный цикл услуги (сервиса) Стратегия услуги (или Построение стратегии) - это основа жизненного цикла услуги. Соответствующая ему публикация обозначает фундаментальность понятия сервис-менеджмента в контексте жизненного цикла услуги. В книге рассматриваются следующие вопросы: развитие рынка IT-услуг, характеристики и типы поставщиков услуг, основные качества услуги и реализация стратегии в процессе жизненного цикла. Ключевыми темами также являются финансовое управление, управление спросом, организационное развитие и стратегические риски. Поставщик должен использовать этап планирования услуги для постановки целей, понимания ожиданий потребителей и рынка сбыта. Построение стратегии предназначено в первую очередь для того, чтобы поставщик услуг смог оценить свои возможности и решить, может ли он справиться со всеми затратами и рисками в соответствии с заявленным Портфелем услуг. Портфель услуг или портфолио - это полный набор услуг, которые предоставляются поставщиком услуг. Портфель услуг используется для управления всеми услугами на протяжении всего их жизненного цикла и включает три категории: 1) услуги в разработке (Service Pipeline) услуги, находящиеся в стадии разработки; 2) каталог услуг для уже используемых или предлагаемых услуг и 3) услуг, выведенных из эксплуатации (retired Services). Проектирование услуги. Для любой IT-услуги самым важным является предоставление бизнесу определенной выгоды или ценности. Поэтому при создании услуги поставщик должен в первую очередь учитывать цели бизнеса. Публикация "Проектирование услуги" представляет собой руководство по моделированию и улучшению услуг, а также рекомендации по управлению ими на практике. Этот этап описывает основные принципы и методы моделирования для трансформации стратегических целей в набор конкретных услуг с определенными качествами. Процесс проектирования фактически является безграничным, если речь идет о новых услугах. Он также включает в себя вопросы изменений и улучшений в рамках жизненного цикла услуги, необходимых для увеличения ее ценности с точки зрения потребителей. Ключевыми темами книги также являются Каталог услуг, Полезность, Производительность и Непрерывность услуги, Уровень управления услуг, которые мы рассмотрим далее. Преобразование услуги. Transition (англ.) - перемещение, переход или изменение с одного состояния (позиции, периода, стадии, темы и т.д.) на другое; переход от подросткового возраста к зрелости. Применительно к услуге эта стадия характеризует собой изменение в ее состоянии, соответствующее перемещению ИТ-услуги из одной стадии жизненного цикла к другой. Соответствующая публикация в библиотеке ITIL представляет собой руководство по тому, как эффективно реализовать требования, сформулированные на стадиях проектирования и построения стратегии, на этапе эксплуатации с контролем рисков, отказов и сбоев. Книга объединяет в себе практики в изменении, конфигурировании, улучшении, публикации и развертывании услуг, а также вопросы управления рисками. Эксплуатация услуги воплощает, по сути, этап "донесения" бизнес-значения услуги от поставщика к заказчикам. Наиболее существенным при этом является эффективное предоставление услуги и ее качественное сопровождение. Книга описывает, как можно обеспечить стабильную эксплуатацию услуги наряду с возможностью внесения изменений в дизайн, масштаб, границы и т.п. Организациям предоставляются инструкции, методы и инструменты для реализации двух методов контроля - превентивного и проактивного. Предложенная в книге информация может быть полезна для принятия решений в вопросах управления доступностью услуги, контроля спроса на услугу, оптимизации нагрузки и решения текущих проблем. Все описанные в книге способы учитывают возможности новых моделей и архитектур, таких как распределенные сервисы, вычисления по схеме "коммунальная услуга"(utility computing), веб-сервисы и электронная коммерция. К слову, utility computing или предоставление вычислительных ресурсов по схеме "коммунальная услуга" - это недавно появившаяся бизнесмодель, когда поставщик услуг получает деньги по факту использования услуги, например, по времени ее использования. В традиционной же бизнес-модели пользователь платит за владение системой (сервисом). Провайдер таких услуг может оптимизировать использование своих ресурсов, учитывая разные нужды потребителей. Здесь просматривается явная аналогия с предоставлением и использованием электроэнергии, газа и большинства других коммунальных услуг, отсюда и происхождение термина. Непрерывное улучшение услуги заключается в описании методов и средств по увеличению ценности услуги путем реализации улучшений на различных этапах жизненного цикла. Этот этап объединяет в себе принципы, практики и методы управления качеством, изменениями и улучшениями производительности. Из публикации организации могут получить рекомендации о том, как постепенно вводить крупномасштабные улучшения в качество услуг, эффективность эксплуатации и непрерывность предоставления услуг. Руководство предназначено для обеспечения обратной связи результатов улучшений с этапами планирования, моделирования и преобразования. Помимо целей потребителей, услуга должна отражать также стратегию и политику поставщика услуг. увеличить изображение Рис. 1.5. Основные связи, входы и выходы этапов жизненного цикла услуги Представленная на рис. 1.5 диаграмма показывает, как различные этапы жизненного цикла услуги зависят от изменений требований бизнеса. Требования формируются на этапе Планирования сервиса в рамках Пакета уровней услуг. Пакет уровней услуг (Service Level Package или SLP) - это определенный уровень полезности и гарантии для отдельного пакета услуг. Каждый SLP разрабатывается для реализации потребностей отдельного профиля бизнес-деятельности. Этот процесс переходит в Проектирование услуги, где решения, принятые на первом этапе, собираются вместе и реализуются в виде Проектной документации услуги. Проектная документация услуги (Service Design Package или SDP) - документы, определяющие все аспекты услуги и требования к ней на каждой стадии жизненного цикла[1]. Фактически это проектная документация, которая разрабатывается для каждой новой услуги, ввода важных изменений или вывода услуги из эксплуатации. SDP переходит в этап внедрения, на котором услуга тестируется, проходит оценку и валидацию. В результате обновляется так называемая Система управления знаниями по услугам, и услуга переходит в стадию эксплуатации. Система управления знаниями по услугам (Service Knowledge Management System или SKMS) - набор инструментов и баз данных, которые используются для систематизации знаний и информации об услуге. Она сохраняет, управляет, обновляет и предоставляет всю информацию, которая необходима поставщику для управления услугой на всех этапах жизненного циклах[1]. Естественно, на протяжении всего жизненного цикла услуга должна улучшаться по мере возникновения необходимости и соответствующих возможностей. Представление управления IT-инфраструктуры в виде комплекса процессов позволяет унифицировать многие аспекты взаимодействия поставщиков и заказчиков услуг. Для каждого процесса определяются роли, цели, задачи, методы и средства, а также входящая и исходящая информация. Таким образом, основным назначением ITILv3 является качественное предоставление и поддержка IT-услуг в соответствии с потребностям бизнеса. Принципиальным отличием третьей версии от второй стал подход к описанию принципов Управления услугами. Помимо группировки процессов Управления услугами в отдельные периоды жизненного цикла, ITILv3 предлагает говорить об IT-услуге в контексте предоставления дополнительной ценности для бизнеса. В ITILv2 IT-служба предлагала бизнесу услуги на базе своей существующей инфраструктуры, стараясь сформулировать в понятных бизнесу терминах характеристики качества услуг. ITILv3 предлагает совершенно иной подход. IT-служба анализирует цели и задачи бизнеса и, исходя из этого, предлагает услуги, которые действительно нужны бизнесу в настоящее время. Применение ITIL не является обязательным, как это происходит, например, со стандартами безопасности или аудита, тем не менее, ITIL в последнее десятилетие стал стандартом де-факто в области управления IT-сервисами во всем мире, включая Россию. Лекция 2: Построение стратегии как этап жизненного цикла услуг Аннотация: Построение стратегии как этап жизненного цикла услуг: назначение, основные принципы и результаты. Типы поставщиков услуг. Принцип "4П". Ключевые слова: требования заказчика, цикла, производительность, стабильность, очередь, ITIL, работ, опыт, права, координац ия, функция, technical, managed application, management, инструментарий, активность, ITSM, товар, значение, специфические активы, улучшение, затраты, процесс управления, стоимость, service, strategy, идентификация, определение, perspective, позиционирова ние, полезность, провайдер, доступ, путь 2.1. Построение стратегии как этап жизненного цикла услуг Современные крупные поставщики услуг обладают схожими характеристиками и возможностями. Главной отличительной особенностью любого поставщика услуг является применяемая им стратегия. При построении стратегии поставщик услуг должен ориентироваться, прежде всего, на цели своего потенциального заказчика. Для этого необходимо четко понимать, какую роль сыграет предоставляемая IT-услуга в бизнесе заказчика. Более того, ввиду крайне быстрого развития ITобласти, в настоящее время поставщику услуг уже недостаточно просто оперативно реагировать на требования заказчика, ему нужно знать заранее, что потребуется заказчику в будущем, то есть предугадывать его потребности. Именно поэтому Построение стратегии является основополагающим этапом в жизненном цикле услуги. Каждый поставщик услуг должен осознавать, что заказчики покупают не конкретные продукты, а средства удовлетворения своих бизнес-потребностей. Для построения стратегии поставщику необходимо учитывать множество факторов, основные из которых: 1. Всё, что окружает IT-услуги сложно: это касается не только индивидуальных особенностей конкретных услуг, но и трудностей, возникающих в результате множества меняющихся и не связанных друг с другом факторов в IT-области. При этом следует различать краткосрочное и долгосрочное планирование, так как поведение рынка, потребителей и самой IT-области отличается в зависимости от рассматриваемого периода. Первоочередной задачей является разработка методов, которые помогли бы организациям в процессе принятия решений и стратегии дальнейших действий. 2. Требования заказчика не всегда четкие, понятные и даже корректные. Многие из них теряются в процессе перехода от проектной документации к реализации услуги. Наиболее важным аспектом стратегического мышления является понимание того, что в итоге должно получиться. То, что получает заказчик вместо своих технических требований к услуге, является основой ее планирования. Понимание потребностей и целей заказчиков предполагает не только знание когда и почему появились конкретные нужды, но и четкое осознание, кто является конечным потребителем IT-услуги. 3. Независимо от контекста, в котором работает поставщик, при построении стратегии ему необходимо учитывать наличие конкуренции. Даже государственные и, так называемые, независимые IT-организации участвуют в конкурентной борьбе. Для поставщика услуг крайне важно знать, какое положение он занимает на рынке, и чем его услуги отличаются от аналогичных услуг конкурентов. Планирование услуги как этап ее жизненного цикла позволяет поставщику разобраться в следующих вопросах: 1. какие услуги следует предлагать? 2. кому следует предлагать услуги? 3. какую выгоду (результат) от использования услуги получат потребители? 4. какую выгоду (результат) от использования услуги получат инвесторы? 5. как развивать внутренние и внешние рынки сбыта? 6. как определить качество сервиса? 7. как заказчики принимают решение о выборе поставщика услуг в условиях конкуренции? 8. как контролировать создание ценности услуги в терминах финансового управления? 9. как распределить имеющиеся ресурсы для наиболее эффективного достижения поставленных целей?[6]. Потребители измеряют результат использования IT-услуги чаще всего в терминах экономики. Для IT-организаций необходимо мыслить об инвестициях в развитие услуг теми же категориями, что и бизнес о необходимости их внедрения. Для любой услуги наиболее существенным преимуществом является адекватная рынку цена. Тем не менее, заказчик не всегда руководствуется этим критерием при выборе услуги. Помимо конкурентной цены необходимо развивать и усиливать другие стороны услуги, например, увеличивать производительность услуги или улучшать ее стабильность. Успех сервис-менеджмента зависит в первую очередь от взаимопонимания между поставщиком и заказчиком. Именно для достижения успеха в его построении и предназначены публикации ITIL. 2.2. Функции и процессы в жизненном цикле услуги В публикации "ITILv3.Построение стратегии услуг" определены и широко используются понятия функций и процессов в жизненном цикле услуги. Функции (Functions) - части организации, специализированные для того, чтобы выполнять определенные виды работ и отвечать за формирование соответствующих результатов. Функции обладают всеми необходимыми для выполнения работы возможностями и ресурсами. Возможности включают в себя собственные методы работы и накопленный опыт. Функции обеспечивают структурированность и стабильность организации [1]. Функции определяют ответственность, права и роли для достижения поставленных целей. Координация функций посредством общих процессов является неотъемлемой частью построения любой организации. Важно понимать, что функции - это не всегда отдельные отделы, то есть принцип "одна функция один отдел" не является истиной. Так, в ITILv3 появились такие функции как Technical Management, Applications Management, то что, по сути, является профессиональной компетенцией (инженеры и администраторы), и не может служить названием для отдела. Процесс - структурированный набор видов деятельности, спроектированный для достижения определенной цели. Процесс может включать в себя роли, ответственность, инструментарий и методы контроля, необходимые для формирования результатов. Процесс может определять политики, стандарты, руководства, виды деятельности и рабочие инструкции, когда это необходимо (рис. 2.1). увеличить изображение Рис. 2.1. Схема базового процесса Основными характеристиками любого процесса являются его активности, их последовательность и зависимость друг от друга. Термин "активность" широко используется в ITIL. Активность или деятельность - набор действий, спроектированный с целью получения определенного результата. Процессы имеют следующие характеристики: 1. Процессы измеряемы, то есть можно измерить процесс каким-либо подходящим методом. Менеджеры стремятся измерить в первую очередь стоимость и качество, а практикующие пользователи - продолжительность и продуктивность процесса. 2. Процессы служат для достижения конкретных результатов. Причина существования процесса - предоставление конкретного результата, который можно идентифицировать и посчитать. 3. Процессы имеют потребителей - каждый процесс предоставляет свои результаты потребителям или инвесторам. Они могут быть внутри или вне организации, но процессы в любом случае должны удовлетворять их ожиданиям. 4. Процессы отвечают за определенный результат. 5. Процессы должны реагировать на определенные события. Пока идет процесс, он должен быть связан со специальным инициализирующим триггером. Понятия функции и процесса часто путают, принимая одно за другое. Чаще всего ошибку вызывает мнение, что если результат можно посчитать, то это процесс. Например, существует ошибочное мнение, что Управление нагрузкой является процессом ITSM. Во-первых, Управление нагрузкой это организационная возможность со своими внутренними процессами и методами. Функцияэто или нет целиком зависит от построения конкретной организации. То есть ошибочно полагать, что управление нагрузкой может быть только процессом. Да, возможно измерить и контролировать нагрузку и определить, адекватна ли она для поставленных целей, но, тем не менее, ошибочно полагать, что если можно измерить, то это процесс. Функции структурируют ресурсы и возможности для процессов. Процессы направляют всё это на достижение поставленной цели. 2.3. Факторы, влияющие на ценность услуги В некоторых случаях ценность услуги можно выразить в экономических терминах, в некоторых нет. Тем не менее, даже если экономическую ценность посчитать невозможно, можно оценить услугу в целом. Ценность услуги определяется не только удовлетворением конечных целей потребителей. Она зависит также от пользовательского восприятия услуги, которое в свою очередь зависит от многих факторов: от атрибутов услуги, которые являются индикаторами ценности для заказчика, от имеющегося у заказчика опыта использования аналогичных услуг, от заслуг конкурентов и т.п. Восприятие услуги также зависит от того, как заказчик воспринимает себя и от его позиции на рынке. Взаимодействие рассмотренных понятий представлено на рис. 2.2. Рис. 2.2. Формирование ценности услуги Пользователи с неохотой покупают товар, в ценности которого есть неопределенность. Поэтому чем меньше осязаема ценность услуги, тем большее значение принимают процессы ее дифференциации и определения. Восприятие ценности услуги заказчиком зависит, прежде всего, от его ожиданий. Ожидания в свою очередь опираются на опыт, рекомендации и другие факторы. На определенном этапе у заказчика формируется некая эталонная ценность услуги, отражающая то, какой должна быть услуга. При этом эталонная ценность может быть нечеткой и опираться на множество факторов. Для поставщика крайне важным является понимание сформированной заказчиком эталонной ценности, которое достигается путем построения правильного диалога с заказчиком, анализа рынка и опыта работы с аналогичными заказчиками. 2.4. Типы поставщиков услуг Поставщики услуг по отношению к организации могут быть как внутренними, то есть фактически являться частью организационной структуры, так и внешними. В ITILv3 выделено три типа поставщиков услуг: 1. Тип 1 В ITILv3 широко используется понятие бизнес-единицы. Бизнес-единица (business unit или BU) - сегмент бизнеса, который имеет свои собственные метрики, планы, доходы и расходы. Каждая бизнес-единица владеет и управляет активами, которые использует для создания товаров и услуг с определенной ценностью. Бизнес-единица, по сути, является некой организационной единицей и может быть частью корпорации или другой организации. Поставщики услуг первого типа (рис. 2.3) закреплены за бизнес-единицами, которые они обслуживают, и финансируются из бюджета этих бизнес-единиц. При этом они находятся в прямом подчинении у бизнеса, а все ключевые решения (определение Портфеля услуг, критерии оценки результатов, объем инвестиций) принимают топ-менеджеры организации. увеличить изображение Рис. 2.3. Поставщики услуг первого типа Основной целью поставщиков услуг первого типа является обеспечение функциональной целостности и эффективности бизнес-единицы, за которой они закреплены. Другими словами, они предоставляют IT-услуги для удовлетворения узкого круга потребностей бизнеса. Успех поставщиков услуг данного типа не измеряется в экономических терминах, так как основной целью их деятельности является не получение прибыли, а предоставление необходимых услуг конкретным бизнес-единицам. У данной модели есть достоинства и недостатки. Основным недостатком является то, что, фактически, развитие поставщика услуг ограничено возможным развитием бизнес-единицы, за которой он закреплен. То, что решения принимает руководство организации, также является своего рода недостатком, так как зачастую оно не разбирается в технических тонкостях ITобласти. Тем не менее, есть и плюсы использования данной модели, основной из которых - бизнес не сталкивается с проблемами, возникающими во время взаимодействия с внешними поставщиками услуг. Также и поставщик услуг первого типа не сталкивается со сложностями свободного рынка. В общем случае, поставщики услуг, обслуживающие более одного заказчика, сталкиваются со многими рисками. Тесная взаимосвязь поставщиков услуг первого типа со своими заказчиками позволяет им избежать этих рисков, так как у их услуг всегда есть потребители. В то же время внешние поставщики услуг обладают большей свободой действий и развития, автономностью и масштабируемостью. Ввиду перечисленных особенностей поставщики услуг первого типа больше подходят для бизнеса, где IT лежит в основе конкурентного преимущества, и, следовательно, требует тщательного контроля непосредственно со стороны руководства организации. 2. Тип 2 Такие деловые функции как финансовое управление, IT, управление персоналом и логистика не всегда являются основой конкурентного преимущества. Отсюда руководителю организации и топменеджерам не обязательно контролировать и управлять ими. Вместо этого услуги таких функций объединяются в отдельную сервисную единицу - Общий поставщик услуг (Service Shared Unit или SSU). SSU(рис. 2.4) как поставщик услуг обладает большей свободой, чем поставщики первого типа. Он может создавать, развивать и поддерживать внутренний рынок сбыта своих услуг аналогично поставщикам, которые работают на свободном рынке. В то же время SSU может использовать возможности корпорации аналогично поставщикам первого типа. Таким образом, SSU находится на пересечении первого и третьего типов. Интересным является то, что поставщики услуг второго типа фактически эмулируют деятельность поставщиков извне, используя их рабочие модели, бизнес-практики и стратегии. Отсюда вытекает и то, что внешние поставщики услуг становятся их основными конкурентами. увеличить изображение Рис. 2.4. Схема провайдера второго типа Конечными пользователями услуг SSU являются бизнес-единицы, инвесторы и корпорация в целом. При этом поставщики услуг второго типа могут предложить более хорошую цену, чем внешние, благодаря преимуществам нахождения в корпорации, внутренним договоренностям и финансированию из бюджета корпорации. Поставщики услуг второго типа, также как и первого, получают преимущества от относительно закрытого рынка. Но в то же время потребители услуг сравнивают их с внешними поставщиками. Плохие поставщики услуг второго типа рискуют быть замещенными внешними поставщиками. Это заставляет их руководство применять лучшие практики, осваивать новые рыночные пространства, формулировать стратегии и развивать отличительные характеристики своих услуг. Тип 3 - внешние поставщики услуг Внешние поставщики услуг находятся вне организационной структуры своих заказчиков, в отличие от предыдущих двух типов. Они действуют на открытом рынке и, как следствие, сталкиваются с рядом трудностей и рисков. Если у поставщиков услуг первого и второго типа всегда есть заказчики, то поставщики третьего типа должны быть конкурентоспособными и постоянно привлекать клиентов. Эти трудности компенсируются гибкостью, масштабируемостью и свободой в действиях и решениях. Поставщики услуг третьего типа обладают большим практическим опытом ввиду обслуживания различных заказчиков и областей рынка, в то время как опыт поставщиков услуг первого и второго типа ограничен корпорацией или узкой областью рынка. Для IT области крайне важно, чтобы поставщик услуг имел опыт предоставления IT-услуги, поэтому этот критерий для многих является ключевым при выборе поставщика услуг. Мотивацией для выбора поставщиков услуг третьего типа также может служить необходимость доступа к опыту, знаниям, ресурсам и более широким возможностям в плане масштабируемости услуги. Кроме того, бизнес всегда стремится к снижению затрат, а внешние поставщики могут предложить конкурентоспособные цены за счет снижения издержек и быстрого реагирования на спрос. Поэтому часто организации гораздо выгоднее обратиться к внешнему поставщику, чем владеть и управлять всеми активами, которые нужны для самостоятельной реализации услуги. С некоторым допущением можно сказать, что провайдеры третьего типа находятся под управлением общей сервисной модели. Это выражается в том, что их ресурсы и возможности распределены среди клиентов, некоторые из которых являются их же конкурентами. Следовательно, конкуренты получают доступ к ценностям друг друга, уменьшая тем самым их значимость. При этом особую роль приобретает обеспечение безопасности. Безопасность всегда является важным аспектом, когда дело касается IT-услуг. Но когда окружение является общим для конкурентов, она принимает особую значимость[6]. Рис. 2.5. Поставщики услуг третьего типа У каждого поставщика услуг есть достоинства и недостатки. Выбор типа поставщика заказчиком зависит от многих факторов: операционных издержек, особенностей индустрии, его компетенции и рисков. Обеим сторонам полезно понимать процесс возникновения операционных издержек: заказчику - чтобы выбрать поставщика, поставщику - чтобы понять, как выбирает заказчик. Операционные расходы - это все расходы, которые понесет бизнес от работы с поставщиком услуг. Помимо собственно стоимости самих услуг, это расходы на поиск и выбор квалифицированного поставщика услуг, определение требований к портфелю услуг, проведение переговоров, измерение производительности, разрешение споров, внесение изменений и улучшений. То, доверит заказчик определенную деловую активность внешним поставщикам или внутренним, зависит от ответа на следующие вопросы: 1. Требует ли деловая активность специфических активов? 2. Как часто используется деловая активность в бизнес-цикле? 3. Насколько сложна деловая активность? 4. Сложно ли определить высокий уровень производительности? 5. Сложно ли измерить уровень производительности? 6. Насколько тесно она связана с другими активностями и активами бизнеса? Ее отделение вызовет много проблем и увеличит сложность бизнес-процессов? В зависимости от ответов на эти вопросы заказчики выбирают тип поставщика услуг. Так, например, если активность используется редко или вовсе в единичном случае, то лучше отдать ее внешнему поставщику услуг. Если она простая, рутинная и не изменяется во времени, то есть стабильна, - также внешнему поставщику услуг. В случае если производительность деловой активности трудно измерить, оценить и проконтролировать - лучше отдать ее внутренним поставщикам услуг (первый и второй тип). Если активность тесно связана с бизнесом, а ее отделение приведет к сложностям и вызовет много проблем - лучше оставить ее внутри организации. Следует заметить, что ответы на представленные выше вопросы могут меняться с течением времени, изменением обстоятельств, появлением новых технологий или требований. 2.5. Фундаментальные основы планирования "В стратегии всё легко, но это не значит, что всё просто". Люди, ответственные за принятие решений, зачастую руководствуются умозрительными моделями и верят в то, что они приведут их к желаемым результатам. Проблемы возникают тогда, когда неправильную модель пытаются использовать для решения практической задачи, не понимая при этом особенностей системы или процесса. Без знания теории и основополагающих принципов работы, невозможно понять, почему казалось бы идеальное решение не подошло для решения конкретной проблемы. Разработка стратегии услуги в первую очередь направлена на улучшение ценности этой услуги. Как уже отмечалось выше, именно стратегия определяет уникальность поставщика услуг. Она нужна не только внешним поставщикам услуг, которые, по сути, являются отдельным коммерческими организациями. Чтобы быть нужными внутри своей корпорации, внутренние поставщики услуг также нуждаются в позиционировании и построении четких планов. Заказчики постоянно пытаются улучшить модели и стратегии своего бизнеса. Они ищут решения, которые смогут предоставить более высокую производительность и эффективность, но хотят при этом, чтобы затраты увеличивались незначительно или вовсе не увеличивались. Такими решениями чаще всего являются инновационные продукты или услуги. Позиция поставщика услуг в бизнесе заказчика и его оценка могут меняться со временем в зависимости от многих обстоятельств, условий и факторов, не подвластных контролю поставщика услуг. Стратегический взгляд на процесс управления услугами требует аккуратного подхода к взаимоотношениям с заказчиком. Первое, что должен учитывать поставщик услуг при разработке стратегии - у него есть конкуренты. Даже если ценность услуги, которую он предоставляет, трудно измерить или оценить, она всё равно должна быть лучше других альтернатив для заказчика. Второе - необходимо четко определить ценность предоставляемых услуг. Ценность, по сути, и есть то, что делает поставщика уникальным для заказчика. Она может быть материальной (увеличение прибыли или уменьшение затрат) и социальной (спасение жизней или сбор налогов). Третье - когда менеджеры говорят о разработке стратегии, то чаще всего подразумевают длинный промежуток времени, в течение которого организация перейдет из одного состояния в другое. В области управления IT-услугами всё немного по-другому. Первая проблема состоит в том, что условия окружения быстро меняются. Темп изменения бизнеса убыстряется, вне зависимости от размера организации и области ее деятельности. Одни возможности появляются, другие исчезают. Мир не ждет, пока кто-то выполнит свои планы и то, что было хорошо сегодня, завтра может оказаться абсолютно непригодным. Поэтому при построении стратегии поставщику услуг крайне важно сохранять гибкость, развивать инновационные решения и быстро реагировать на изменяющиеся условия. Вторая проблема заключается в определении ценности услуги. В то время как стратегия, по сути, сложна, принципы, лежащие в ее основе, просты. Фактически, есть только два пути, с помощью которых один поставщик услуг может стать лучше другого - заставить заказчика платить больше за услуги или снизить их стоимость. Отсюда два вопроса - чем мотивировать заказчика платить больше или как использовать меньше ресурсов и тем самым снизить затраты? Поставщик может создать ценность услуги благодаря отличительным характеристикам, но может быть не способным при этом сохранить их уникальность с течением времени. Более того, условия определения ценности меняются. Приведем пример из книги "ITILv3.Service Strategy". Поставщики услуг переводят свое производство в другие страны, например, с меньшими налогами. Первые, кто воспользовался подобной схемой, получили преимущество перед своими конкурентами, так как за счет снижения издержек снизили цену на предоставляемые услуги. Но когда большое количество поставщиков услуг стало работать по такой схеме, услуги подешевели у всех. Это порадовало потребителей, но плохо сказалось на поставщиках услуг - отличительная особенность исчезла. То есть ценность была создана, но поставщики услуг не смогли ее сохранить. Достижение конкурентного преимущества почти во всех случаях базируется на балансе, регулировании и обновлении трех базовых составляющих: фокус и позиция на рынке, отличительные возможности, анатомия производительности (рис. 2.6). Рис. 2.6. Достижение конкурентного преимущества Фокус и позиция на рынке - представляет собой освещение поставщиком услуг своей позиции на рынке. Рынок сбыта определяется результатами, которые потребители хотят получить с помощью одной или нескольких услуг. В эту категорию входит построение и управление Портфелем услуг, выбор оптимального масштаба, идентификация и включение в стратегию альтернативных рынков сбыта/новых заказчиков. Для поставщиков услуг всех типов крайне важным является определение рынка сбыта, понимание его динамики и целей своего конечного потребителя. Поставщикам первого и второго типов этот аспект построения стратегии дается гораздо проще, так как они заранее знают своего потребителя и рынок сбыта, благодаря чему изначально имеют преимущества. Отличительные возможности - освещение процессов создания и использования набора возможностей, уникальных и неповторимых для данного поставщика. Посредством этих возможностей поставщик услуг предоставляет заказчику ценность. Эта часть построения стратегии отражает взаимодействие ресурсов, возможностей и процесса создания ценности. Чем больше у поставщика услуг отличительных возможностей, тем более высок шанс, что заказчик обратится именно к нему. Отличительные возможности лежат в основе конкурентного преимущества. Поставщики услуг должны четко понимать, какие именно отличительные возможности вносят больший вклад в процесс достижения заказчиком желаемых результатов. Более того, он должен развивать эти отличительные возможности и следить за тем, чтобы они были наглядны и очевидны для заказчика. Анатомия производительности - освещение процесса создания организационных и поведенческих особенностей, с помощью которых поставщик услуг двигается к намеченной цели в условиях конкуренции[6]. Анатомия производительности содержит в себе устоявшиеся в мире организационные взгляды, которые руководство конкретной организации может применить на практике. Например, "услуги являются стратегическими активами" или " непрерывное улучшение и обновление услуг является реальной и постоянной необходимостью". 2.6. Четыре "П" Построения стратегии В книге "ITILv3.Service Strategy" описывается четыре точки входа для построения стратегии, так называемые Four Ps of Strategy - Perspective (Перспектива), Positions (Позиции), Plans (Планы) и Patterns (Принципы). Именно они определяют форму, которую принимает в итоге стратегия (рис. 2.7). Рис. 2.7. Четыре "П" стратегии Перспектива определяет направление развития поставщика услуг, его ценности и общую цель. Стратегическая перспектива формирует философию взаимодействия с заказчиком и методы предоставления услуг. Например, поставщик услуг второго типа для международной юридической компании может сформировать ее следующим образом :"Мы будем лучшим провайдером в своем классе для нашей юридической фирмы". Поставщику услуг третьего типа больше подойдет "Фокусируйся на пользователе, а все остальное приложится" или "Наша цель улучшить жизнь пользователей". Перспектива в отличие от планов или позиций является более постоянной и устойчивой к переменам. В книге "ITILv3.Service Strategy" приводится пример индустрии швейцарских часов. В начале 1970-х годов стали использовать кварц в качестве колебательной системы часов. Это позволило удешевить производство в десятки раз, сохранив качество на достойном уровне. Тем не менее, швейцарские производители посчитали, что использование этой технологии идет вразрез с профессиональным мастерством производства часов. Японские производители, напротив, стали активно использовать кварц и вытеснять швейцарские часы. Так было до тех пор, пока швейцарские производители не изменили свою маркетинговую кампанию, переориентировавшись на богатых клиентов, так называемый, luxury - сегмент рынка. В настоящее время швейцарские часы являются своего рода образцом качества, стиля и свидетельством достатка своего обладателя. Позиция. Позиционирование предполагает нахождение ответов на ряд вопросов, например: Следует повышать ценность услуг или снижать затраты? Следует предоставлять специализированные услуги или услуги широкого назначения? Следует делать упор на гарантию качества или полезность? Провайдер первого типа может строить позицию под лозунгом "знаю, что производить" или "чувствую потребителя". Позиционирование чаще всего основывается на текущих потребностях бизнеса и выражается в том, чем этот поставщик услуг отличается от других с точки зрения потребителя. Выделяют три типа наиболее распространенных позиций: • позиционирование на основе вида услуг (variety-based positioning) предполагает, что поставщик специализируется на определенном виде потребностей заказчиков (рис. 2.8). Рис. 2.8. Позиционирование на основе вида услуг Этот подход подразумевает сужение спектра услуг, но увеличение их возможностей с целью максимального удовлетворения конкретного вида потребностей. Развитие возможно преимущественно за счет новых возможностей установленного каталога услуг, а не за счет введения новых услуг. То есть поставщик услуг может сначала обслуживать одну бизнес-единицу, потом несколько бизнес-единиц в рамках компании или несколько компаний в рамках региона. • позиционирование на основе потребностей (needs-based positioning) предполагает, что поставщик услуг старается удовлетворить все или почти все потребности заказчика определенного типа (рис. 2.9). Рис. 2.9. Позиционирование на основе потребностей Это требует расширения каталога услуг, так как поставщику необходимо удовлетворить потребности разного вида. Развитие возможно преимущественно за счет появления новых услуг в каталоге. • позиционирование на основе доступа (access-based positioning) предполагает, что поставщики услуг делают своей отличительной особенностью готовность предоставлять услуги с учетом месторасположения, масштаба и структуры заказчика (рис. 2.10). Рис. 2.10. Позиционирование на основе доступа Заказчики отличаются размером, структурой и границами работы. Сотрудники некоторых корпораций мобильны, но, тем не менее, хотят получить доступ ко всем коммуникациям. Сотрудники других организаций работают стационарно, но в удаленных уголках планеты. Данный вид позиционирования предполагает удовлетворение потребностей бизнеса с учетом всех особенностей, которые его сопровождают. Естественной в данном случае является узкая специализация. Стратегия данной формы наиболее опасна, так как очень уязвима: неожиданное изменение в бизнесе или сегменте рынка может привести к резкому снижению спроса и, как следствие, краху поставщика услуг. План описывает последовательность решений и действий для перехода от того, что есть к тому, что должно быть. План предоставляет последовательность действий, которые необходимо осуществить для достижения стратегических целей. Преимущественно рассматриваются вопросы, связанные с бюджетом, портфелем услуг, развитием новых услуг, инвестициями и улучшением. План может,например, детализировать: "Как мы сможем предоставить ценные или дешевые услуги?". Принцип описывает фундаментальный путь организации.Принцип в данном случае представляет собой последовательность действий и решений, которые относительно постоянны во времени. Принципы формируются исходя из успешных результатов - если что-то однажды принесло успех, это можно применить еще раз. Поставщик услуг, который предоставляет специализированные услуги, требующие высокой квалификации, использует так называемую стратегию "высокого класса". Тот, кто поставляет надежные услуги, использует стратегию "высокой гарантии качества". Требования и условия динамичны, и поставщик услуг может начать со стратегии одной формы, а закончить другой. Например, поставщик услуг может начать с построения перспективы, то есть определения цели и направления организации. Затем он может решить использовать позиционирование, основанное на возможностях, ресурсах и политиках организации. Это может быть достигнуто с помощью тщательно продуманного плана. Достигнув однажды желаемых результатов, поставщик услуг может управлять своей позицией с помощью системы хорошо понятных решений и действий - принципов. Лекция 3: Процессы в рамках Построения стратегии. Портфель услуг и Каталог услуг Аннотация: Ключевые деятельности в рамках Построения стратегии: определение ценности услуги, формирование Портфеля услуг и Каталога услуг, Управление финансами, Моделирование спроса, Оптимизация предоставления услуг, Возврат инвестиций. Ключевые слова: активы, потенциал, увеличение производительности, класс, производительность, очередь, кредит, доступ, ПО, идентификация активов, бизнеспроцессы, определение, отображение, CMS, service, strategy, цикла, пункт, анализ, безопасность, п олезность, портфель, улучшение, контроль, management, управление рисками, затраты, поиск, выход, прибыль, элемент каталога, сделка, LOS, информация, функция, ITIL, поддержка, понятность, коммерческое предложение, VCD, отношение, значение, чистая прибыль, стоимость, ROI, выходные параметры, внутренняя норма доходности, IRR 3.1. Определение возможностей и ценности услуги Организации стремятся удовлетворить потребности бизнеса, используя любые доступные им активы. Активы могут принадлежать бизнесу или быть доступными в результате различных финансовых соглашений. Для достижения поставленных целей менеджеры стремятся использовать весь заложенный в активах потенциал. При этом в окружении бизнеса имеется множество ограничивающих факторов, которые уменьшают результативность использования активов, и, следовательно, деятельности организации в целом. Главными ограничивающими факторами являются риски и издержки, которые возникают вследствие наличия сложностей, противоречий и неопределенности в окружении бизнеса. Одной из основных задач менеджеров является выбор наиболее подходящих средств для достижения поставленных целей. Услуги и есть те средства, которые могут использовать менеджеры для увеличения производительности активов бизнеса. Отсюда следует, что ценность услуги лучше всего измерять в улучшении конечных результатов заказчика, вызванном увеличением производительности активов в результате использования услуги. Важно понимать, что не все услуги нацелены на увеличение производительности активов, хотя это и есть самый большой класс услуг. Некоторые услуги предназначены для сохранения текущего уровня производительности, некоторые - для восстановления производительности после различных неблагоприятных событий, например, сбоев. В общем случае можно сказать, что основной аспект применения услуг - предотвращать или ослаблять колебания производительности активов заказчика. Производительность активов заказчика должна быть основным вопросом сервисменеджмента, так как без активов заказчика нет базиса для определения ценности услуг. Заказчики услуг в свою очередь стремятся предоставить некую ценность своим клиентам. Активы бизнеса являются для них средствами обеспечения и увеличения этой ценности. Например, ценность банка, дающего деньги в кредит, создается оперативной обработкой заявок на кредит (рис. 3.1). Рис. 3.1. Пример анализа результатов на выходе В результате клиенты банка получают доступ к требуемым финансовым средствам, а банк получает выгоду в виде процентов покредиту. Процесс кредитования является активом бизнеса, производительность которого определяет результаты бизнес-деятельности. Для поставщика услуг крайне важно понять бизнес, который он обслуживает или собирается обслуживать. Это включает в себя идентификацию активов бизнеса и результатов, к которым он стремится. Поставщик услуг должен искать возможности для внедрения своих услуг, так как некоторые бизнес-процессы плохо подходят для внедрения услуг с целью увеличения производительности. Другие процессы возможно поддержать только услугами, которые в настоящий период находятся на этапах Проектирования и Планирования. Для поставщика услуг самые большие возможности скрываются в бизнес-процессах, производительность которых была высокой, но снизилась под воздействием неких неблагоприятных событий или изменений в окружении бизнеса. Определение ценности услуги упрощается, если появляется возможность визуализировать выходы бизнес-процессов, для которых она предназначена. Отображение результатов заказчика на услуги выполняется в рамках Системы управления конфигурацией. Система управления конфигурацией (Configuration Management System или CMS) - набор инструментов и баз данных, которые используются поставщиком услуг для управления данными о конфигурациях. CMS также содержит информацию об инцидентах, проблемах, известных ошибках, изменениях и релизах; и может содержать данные о сотрудниках, поставщиках, местоположениях, бизнес-единицах, заказчиках и пользователях. CMS включает в себя инструменты для сбора, хранения, управления, обновления и представления информации обо всех конфигурационных единицах и их взаимоотношениях. CMSнаходится под управлением процесса Управления конфигурациями и используется всеми процессами Управления ИТ-услугами[1]. В книге "ITILv3.Service Strategy" выделены две ключевые роли - Менеджеры по взаимоотношениям с бизнесом и Менеджеры продуктов. За установление прочных взаимоотношений с заказчиком ответственны менеджеры по взаимоотношениям с бизнесом (Business Relationship Managers или BRM). Их задача фокусироваться на заказчике, определять его бизнес-процессы и результаты, которых он ждет. Во многих организациях BRM известны как рекламные агенты, представители или менеджеры продаж. BRM тесно сотрудничают с Менеджерами продуктов (Product Managers), которые ответственны за развитие и управление услугами на всех этапах жизненного цикла. Они также несут ответственность за производственный потенциал, каналы распространения услуг, решения и пакеты, представленные в Каталоге услуг. Если BRM сфокусированы на заказчике, то менеджеры продуктов - на услугах. Формирование ценности услуг в зависимости от результатов заказчика гарантирует то, что менеджеры будут планировать и управлять услугами с точки зрения выгоды заказчика. Услуги отличаются в зависимости от того как и в каком контексте они создают ценность. Профиль услуги является аналогом бизнес-модели. Он определяет, как поставщики услуг действуют в интересах заказчика для того, чтобы создать ценность (рис. 3.2). увеличить изображение Рис. 3.2. Взаимосвязь бизнес-моделей поставщика услуг и активов заказчика Активы заказчика являются контекстом, в котором создается ценность услуги, так как они влияют на результаты, которые хочет получить заказчик. Заказчики владеют различными типами активов (Ay), зависящих от таких факторов, как особенности индустрии, клиенты, конкуренты, применяемые бизнес-модели и стратегии. Комбинация профиля услуги и актива заказчика представляет собой пункт в Каталоге услуг. Несколько услуг в Каталоге могут относиться к одному профилю (Ux). В то же время несколько профилей услуг могут соотноситься с одним активом заказчика при стратегии, основанной на активах. Если поставщик услуг применяет стратегию, основанную на полезности, то профиль одной услуги может быть использован для поддержания нескольких типов пользовательских активов (рис. 3.3). Рис. 3.3. Позиционирование на основе доступа и позиционирование на основе полезности Таким образом, стратегия поставщика услуг определяет содержание и структуру Каталога услуг. Для поставщика услуг удобно визуализировать услуги в виде моделей, состоящих из различных комбинаций профилей услуг и пользовательских активов. При этом некоторые комбинации могут принести больше пользы заказчикам по сравнению с другими, несмотря на то, что они могут состоять из одних и тех же профилей услуг и активов. После такой визуализации, менеджеры должны провести анализ. Если много моделей включают в себя профиль "безопасность", это свидетельствует о наличии возможности для предложения в данной области. Представленный принцип визуализации может быть полезен для связи и координации функций и процессов сервисменеджмента. 3.2. Формирование Портфеля услуг После того, как поставщик услуг определил возможности для сбыта, он должен создать соответствующие им предложения на продажу. Рынок сбыта определяется набором бизнеспроцессов заказчика и их результатами, которые могут быть обслужены услугами поставщика. Примерами результатов, которые хочет получить заказчик на выходе бизнес-процесса, могут послужить следующее: • Сайт электронной коммерции должен быть надежно соединен с системой управления складом. • Необходимо обеспечить безопасность и контроль за ключевыми бизнес-приложениями. • Необходимо обеспечить непрерывность бизнеса. • Онлайн-система оплаты счетов должна предоставлять больше сервисов для оплаты и т.п[6]. Выше перечислены результаты, которых хочет достичь заказчик. Каждый из них связан с одним или несколькими активами бизнеса: людьми, информацией, инфраструктурой и т.п. Производительность активов увеличивается с помощью услуг. Каждый результат может быть достигнут множеством путей (рис. 3.4). Заказчик выберет тот, который влечет за собой меньше рисков и затрат. Рис. 3.4. Определение рынка сбыта по тому, что нужно заказчикам Заказчики часто выражают неудовлетворенность поставщиком услуг, несмотря на то, что сроки и условия, оговоренные в соглашениях, соблюдены. Неудовлетворенность заказчика связана в первую очередь с тем, что ему не всегда понятна ценность услуги. Услуги часто определяют в контексте ресурсов, которые стали доступны заказчику в результате использования этих услуг. Такое определение не показывает то, чем полезны услуги и как они помогли заказчику в достижении его целей. Как следствие, заказчик не находит оправдания своих затрат на услуги. Более того, он отказывается улучшать услуги, если непонятно точно, нужны ли эти улучшения его бизнесу. Улучшения могут быть одобрены и профинансированы заказчиком только, если их полезность для бизнеса очевидна. Вот почему крайне важно определять услуги с точки зрения результатов, которые получит заказчик. В ITILv3 широко используются такие понятия как портфель услуг и каталог услуг. Необходимо разделять и понимать их. Портфель услуг(Service Portfolio) - полный набор услуг, которые управляются поставщиком услуг. Портфель услуг используется для управления полным жизненным циклом всех услуг. Он состоит из трех частей (рис. 3.5): • каталог услуг - отображает услуги, находящиеся в эксплуатации или полностью готовые к ней; • услуги в разработке; • услуги, выведенные из эксплуатации. Рис. 3.5. Структура портфеля услуг Портфель услуг отображает существующие обязательства поставщика услуг по контрактам, а также дальнейшее развитие и улучшение услуг в соответствии с принятыми планами и стратегиями (рис. 3.6). Рис. 3.6. Портфель услуг В Портфель услуг входят также услуги третьих сторон, которые являются неотъемлемой частью предложения заказчику. При этом некоторые из услуг сторонних поставщиков видны заказчику, некоторые - нет. Использование портфеля услуг позволяет менеджерам расставлять приоритеты инвестиций в услуги и правильно распределять ресурсы. Изменения в Портфеле услуг управляются политиками и процедурами. Портфель услуг отображает все ресурсы, которые были выделены в прошлом или заняты на настоящее время на всем жизненном цикле услуг. Контроль и управление Портфелем услуг возложено на Управление портфелем услуг (Service Portfolio Managementили SPM). SPM рассматривает услуги в терминах предоставляемой ими ценности для бизнеса. SPM как набор непрерывных и динамичных процессов включает в себя следующее: 1. распределение ресурсов 2. определение полного перечня услуг, проверка и утверждение Портфеля услуг 3. минимизация затрат и рисков 4. максимизация ценности услуг 5. соблюдение баланса спроса и предложения Основной задачей SPM является управление рисками и затратами с целью увеличения ценности услуг. SPM помогает менеджерам понять требования заказчиков к качеству услуг, а также посчитать затраты на предоставление соответствующих услуг. Задачей менеджеров является поиск способов для снижения затрат в процессе управления качеством предоставляемых услуг. Каждый вход, выход или перемещение в Портфеле услуг одобряется только при наличии выделения соответствующего бюджета и плана по возврату инвестиций. Каталог услуг(Service Catalogue) - это единственная часть Портфеля услуг, которая приносит прибыль и окупает затратыпоставщика на услуги. Это та часть Портфеля услуг, которая видна заказчику. Элементами Каталога услуг являются услуги, находящиеся на стадии Эксплуатации или готовые к ней. Таким образом, услуги из Каталога услуг могут быть предложены заказчикам в настоящее время. Любая услуга может войти в Каталог услуг только после того, как затратам и рискам, связанным с ней, было уделено должное внимание со стороны менеджеров и разработчиков. При этом цена услуги может быть отредактирована в зависимости от конкретного заказчика. Формирование Каталога услуг является существенной частью этапа Построения стратегии, так как он является проекцией существующих возможностей поставщика услуг. В общем случае заказчику не интересны услуги, находящиеся на стадии разработки или вышедшие из эксплуатации. Фактически, услуги, которые поставщик услуг может предложить в будущем, в настоящее время не представляют ценности для заказчика. Ему интересно то, что может предложить поставщик услуг сейчас - то есть услуги, входящие в Каталог услуг. Для того чтобы добавить или удалить услугу из Каталога необходимо одобрение тех, кто управляет этапом Внедрения, последующим причинам: • если элемент добавлен в Каталог услуг, он должен быть доступен для заказчиков. То есть должна быть полная уверенность, что услуга - законченный продукт, который может быть полностью поддержан поставщиком. Спешно добавленные услуги могут принести значительные убытки, как поставщику, так и заказчику. • Большинство услуг в Каталоге услуг находятся непосредственно в эксплуатации, то есть являются объектами каких-то соглашений с заказчиками. Неутвержденные изменения в Каталоге услуг могут привести к тому, что условия соглашений перестанут выполняться. • Добавление услуги в Каталог услуг означает выделение ресурсов под текущих и потенциальных заказчиков. Здесь важным является процесс распределения ресурсов, так как может возникнуть ситуация, когда востребованные ресурсы будут заняты на поддержку нерентабельных услуг[6]. Каталог услуг также служит для связи спроса и предложения. Активы заказчика, привязанные к результатам, которых от них ждет бизнес, являются источниками спроса (рис. 3.7). увеличить изображение Рис. 3.7. Взаимодействие Каталога услуг и Управления спросом У заказчиков есть ожидания определенного уровня качества и полезности услуг. Если какойто элемент Каталога услуг может удовлетворить этим ожиданиям, между поставщиком услуг и заказчиком заключается сделка. Таким образом, Каталог услуг служит неким входом для того, чтобы заказчик приобрел услуги. Именно в Каталоге услуг услуги разбиваются на составные части - активы, системы и процессы. Они отображаются с точками входа в контексте их использования и поддержки. Элементы в Каталоге услуг группируются в Линии услуг (Lines of Service или LOS) на основе совпадения бизнес-активности, которой они могут способствовать. Это помогает управлять распределенными ресурсами с целью поддержания производительности услуг и спроса на них на должном уровне. Услуги в Каталоге услуг считаются жизнеспособными, если они функционируют выше финансового порога. Другими словами, если они окупают затраты на них и приносят какуюто прибыль поставщику услуг. При этом поставщик услуг старается развивать и улучшать эти услуги с целью получения большей прибыли: предлагает новые возможности, маневрирует ценой и максимально приближает их свойства к тому, что требуется заказчикам. Если производительность услуги падает ниже финансового порога, поставщик услуг должен принять решение о том списать ее или нет. При этом услуги с плохой производительностью могут находиться в Каталоге услуг по объективным причинам. Например, предоставление таких услуг может являться обязательством поставщика по ранее заключенным соглашениям с заказчиком. В Каталоге услуг могут находиться также услуги третьих сторон. Они предоставляются заказчикам вместе с собственными услугами поставщика. Услуги в разработке(Service Pipeline) - часть Портфеля услуг, состоящая из услуг, находящихся в развитии в настоящее время, следовательно, недоступных заказчикам. Эти услуги станут доступны после завершения проектирования, тестирования и развертывания. Эта часть Портфеля услуг отображает потенциал и стратегию поставщика услуг. Услуги, выведенные из эксплуатации(Retired Services) - часть Портфеля услуг, состоящая из услуг, выведенных из среды промышленной эксплуатации. Информация о таких услугах сохраняется для будущего использования в случае возникновения необходимости. В общем случае эти услуги не доступны заказчикам. Тем не менее, они могут быть снова введены в эксплуатацию при наличии соответствующего соглашения между бизнесом и IT и одобрения вышестоящего руководства поставщика услуг. 3.3. Управление финансами Управление финансами(Financial Management) - функция и процессы, ответственные за управление бюджетом, учет и возмещение затрат поставщика услуг. Управление финансами является стратегическим инструментом для поставщиков услуг всех типов. Даже внутренние поставщики услуг обязаны действовать в соответствии с уровнями финансовой прозрачности и отчетности бизнес-единиц, которые они обслуживают, и своих внешних конкурентов. Управление финансами предоставляет бизнесу и IT количественную финансовую оценку ценности услуг, стоимости активов, лежащих в основе предоставления этих услуг, а также методы и инструменты для оперативного прогнозирования. Управление финансами является средством решения такого сложного вопроса как восприятие IT-области бизнесом. IT-организации всё более часто включают Управление финансами в такие процессы как: • принятие решений; • ускорение изменений; • управление Портфелем услуг (SPM); • финансовый контроль; • оперативное управление; • создание и фиксирование ценности [6]. В ITIL под организациями, которые ведут бизнес, чаще всего подразумеваются заказчики, а поставщики услуг выступают лишь как поддержка бизнеса. По сути же IT-организации, предоставляя услуги, также ведут бизнес, а для любого бизнеса крайне важно правильное Управление финансами. Поставщик услуг должен следить за балансом спроса и предложения, минимизировать затраты и увеличивать ценность предоставляемых услуг. На рис. 3.8 представлены моменты, общие для бизнеса и IT-организаций. Рис. 3.8. Общее между бизнесом и IT Управление финансами является источником информации, которая помогает IT-организации ответить на следующие вопросы: 1. Какая из стратегий наиболее эффективна: получение более высокой прибыли, снижение затрат или обеспечение широкого выбора услуг? 2. Затраты на какие услуги самые высокие и почему? 3. Какие типы услуг и в каких объемах наиболее востребованы? Какие финансовые вложения необходимы для их поддержки? 4. Насколько эффективны используемые модели предоставления услуг по сравнению с аналогичными моделями конкурентов? 5. Привел ли стратегический подход к проектированию услуг к конкурентоспособной цене за эти услуги? На что лучше ориентироваться: снижение риска или увеличение качества? 6. Какие основные недостатки у наших услуг? 7. На каких функциональных областях лучше сконцентрироваться при построении стратегии Непрерывного улучшения услуг? Без информации, которую предоставляет Управление финансами невозможно корректно ответить на эти вопросы. Отсутствие правильного Управления финансами может нивелировать весь смысл построения стратегии, дизайна и любых тактических решений. Управление финансами обеспечивает прозрачность и понятность затрат на услуги как для бизнеса, так и для самого поставщика услуг. Управление финансами включает в себя следующие основные задачи: • оценка ценности услуг; • моделирование спроса; • управление Портфелем услуг; • оптимизация предоставления услуг; • планирование соответствия; • анализ инвестиций в услуги; • формирование бухгалтерской отчетности; • соответствие; • моделирование переменных затрат. Рассмотрим более подробно перечисленные задачи. 1. Оценка ценности услуг (Service Valuation) - измерение полных затрат на предоставление услуги для поставщика и полной ценности этой услуги для бизнеса. Оценка ценности услуги используется для того, чтобы помочь бизнесу и поставщику услуг прийти к соглашению о ценности услуги. Основная цель этого процесса - нахождение цены услуги, которая будет восприниматься заказчиком как справедливая, и позволит поставщику услуг получить прибыль и поддерживать услугу. Как уже отмечалось ранее, ценность услуги формируется из двух основных параметров полезности и гарантии качества. Эти параметры требуют финансового выражения. Отсюда Оценка ценности услуг использует две ключевые концепции оценки: o Цена обеспечения (Provisioning Value) - фактическая цена обеспечения услуги для поставщика услуг. Эта цена включает в себя затраты на ресурсы, которые задействованы для предоставления услуги, основные из которых: стоимость лицензий на программное обеспечение; покупка или аренда оборудования; человеческие ресурсы; коммунальные услуги, поддержка сети, информационного центра и другие расходы на средства обслуживания; налоги, амортизация, проценты по займам. Сумма этих затрат представляет собой минимальную цену на услугу - тот самый финансовый порог, ниже которого поставщик услуг не будет опускаться при формировании коммерческого предложения. o Потенциал ценности услуги (Service Value Potential) - оценка, основанная на ценности услуги с точки зрения заказчика или предельных значений полезности и гарантии предлагаемой услуги в сравнении с использованием собственных активов заказчика. Сначала в качестве основы устанавливаются элементы услуги, которые могут принести ценность заказчику. Затем каждый элемент оценивается отдельно в соответствии с предоставляемой им ценностью. В конце суммы от всех элементов складываются вместе с затратами на их предоставление, чтобы определить окончательную цену услуги. Взаимосвязь двух концепций представлена на рис. 3.9. Рис. 3.9. Пользовательские активы как основа формирования ценности услуги 2. Моделирование спроса Плохое понимание спроса и его влияния на все процессы может привести к большим затратам и рискам. В частности, спрос тесно связан с количеством услуг, которые заказчик будет "производить". Это требует от Управления финансами способности предвидеть и измерять возможные колебания бюджета от любых изменений в спросе. Для оценки спроса на услуги, принятия решений и контроля ключевой является информация из Каталога услуг и Управления мощностями. Управление мощностями (Capacity Management) - процесс, отвечающий за своевременное и эффективное по затратам соответствие мощности услуг и ITинфраструктуры требованиям согласованных Целевых показателей уровня услуги. Управление мощностями принимает во внимание все ресурсы, необходимые для предоставления услуг, а также производит краткосрочное, среднесрочное и долгосрочное планирование требований бизнеса[1]. Важную роль при моделировании спроса играет определение Совокупной стоимости использования услуги для заказчика. Совокупная стоимость использования (Total Cost of Utilization или TCU) - полные затраты заказчика на использование услуги на протяжении всего ее жизненного цикла. Моделирование спроса предназначено для оценки ожидаемого использования услуги бизнесом и необходимых при этом ресурсов поставщика услуг. Каталог услуг влияет на моделирование спроса, но для любой IT-организации должна быть и обратная связь моделирование спроса должно влиять на Каталог услуг. 3. Управление Портфелем услуг Управление Портфелем услуг должно быть основано на Управлении финансами. Понимание, а главное, финансовая оценка полной стоимости предоставления услуги позволяет поставщику сравнивать свои услуги с аналогами у конкурентов. Это сравнение необходимо для принятия ключевого решения - выгодно ли поставщику услуг предоставлять ту или иную услугу. 4. Оптимизация предоставления услуг Оптимизация предоставления услуг (Service Provisioning Optimization или SPO) анализ финансов и ограничений услуги для принятия решения в случае, если альтернативный подход к предоставлению услуги может уменьшить затраты или улучшить качество. Управление финансами является ключевым для SPO. Основными кандидатами SPO являются услуги, которые были отмечены на удаление из Каталога услуг. Предоставление услуги может стать невыгодным для поставщика услуг, если конкуренты могут предложить более высокое качество или полезность или более низкую цену. Удаление услуги может стать следствием и других факторов, например, банального устаревания. Управление финансами обеспечивает IT-организацию информацией о существующих затратах на услугу, альтернативных методах предоставления услуги, возможностях ее использования в комбинациях с другими услугами, финансовых структурах и т.п. Эта информация является ключевой для формирования Портфеля услуг. 5. Доверительное планирование Одной из целей Управления финансами является обеспечение должного финансирования на предоставление и сопровождение услуг. Планирование выполняет количественную оценку спроса на услуги в будущем. Входные данные должны быть собраны со всех областей деятельности IT-организации и бизнеса и отражать картину в целом. "Доверительное" здесь значит некую уверенность в том, что применяемые в Управлении финансами данные и модели спроса и предложения имеют высокий уровень достоверности. Соответствие информации важно по двум основным причинам: o данные играют критическую роль в достижении Управления финансами поставленных целей o возможность некорректных данных подрывает значение принятых решений. Так как Управление финансами предоставляет информацию для принятия многих решений в сервис-менеджменте, уровень соответствия этой информации обязан быть высоким. Любая неуверенность в ее точности и аккуратности вызовет недоверие к ценности Управления финансами в целом. 6. Анализ инвестиций в услуги. Целью анализа инвестиций является извлечение стоимостных показателей для всего жизненного цикла услуги. Стоимостные показатели основываются на полученной ценности услуг и затратах на всем жизненном цикле услуги. 7. Учет затрат Учет затрат в области сервис-менеджмента требует иных методов и средств нежели традиционный бухгалтерский учет. Учет затрат (Accounting) - процесс, отвечающий за идентификацию фактических затрат на предоставление услуги, их сопоставление с плановыми затратами, и управление отклонениями от Бюджета[1]. Управление финансами играет связующую роль между корпоративной финансовой системой и сервис-менеджментом. Результаты функции Учета затрат являются входными данными для планирования и помогают лучше понять и детализировать процессы снабжения и потребления. Выделяют следующие способы классификации затрат: o Капитальные/эксплуатационные затраты - классификация отражает различные методологии бухгалтерского учета, которые требует бизнес и регуляторы. o Прямые/косвенные затраты прямые затраты относятся к конкретной услуге, которая и является их единственным потребителем; косвенные затраты или "распределенные" затраты - затраты, которые распределены между множеством услуг так, что каждая услуга потребляет какую-то часть от общей суммы. o Постоянные/переменные затраты - эта классификация основана на договорных обязательствах по времени или цене. Стратегический смысл такой классификации в том, что бизнес должен стремиться к оптимизации постоянных затрат и минимизировать переменные затраты с целью обеспечения максимальной предсказуемости и стабильности. o Единицы затрат - это обычно легко исчислимые (например, численность сотрудников, количество лицензий на программное обеспечение) или измеримые объекты (например, загрузка ЦПУ, потребленная электроэнергия)[1]. Единица затрат идентифицирует единицу расхода, рассчитываемого для конкретной услуги. 8. Соответствие Соответствие (compliance) - обеспечение уверенности в соблюдении стандартов или набора руководящих документов, полноте и целостности чего-либо, использовании определенных установленных правил [1]. В контексте Управления финансами соответствие означает использование методов и практик надлежащей точности и стойкости. Это относится к оценке финансовых активов, капитализации, определению дохода, контролю доступа и безопасности и т.п. Соответствие легко достижимо, если применяемые методы и практики задокументированы. Поставщику услуг крайне важно знать стоимость обеспечения соответствия предоставляемых услуг. Услуги, которые могут быть предоставлены по заданной цене одной области, возможно, не смогут быть предоставлены по той же цене другой области именно из-за проблем с соответствием стандартам, законам, установленным нормам и т.п. 9. Моделирование переменных затрат Моделирование переменных затрат (Variable Cost Dynamics или VCD) - техника, используемая для понимания, каким образом полные затраты подвергаются влиянию множества комплексных изменяющихся элементов (переменных), вносящих каждый свой вклад в предоставление услуг[1]. Ниже представлен короткий перечень возможных переменных затрат, которые могут быть включены в анализ: o количество и типы пользователей; o количество лицензий на программное обеспечение; o механизмы доставки; o стоимость сопровождения хранилища данных; o количество и типы ресурсов; o стоимость добавления еще одного устройства хранения; o стоимость добавления еще одного пользователя[6]. Количество переменных затрат зависит от типа анализируемой услуги. Ввиду этого VCD содержит большое количество сценариев и допущений, каждый из которых использует свой набор инструментов для подсчета переменных затрат. 3.4. Возврат инвестиций Возврат инвестиций в традиционном понимании значит окупаемость вложений, то есть отношение полученной прибыли к вложенному капиталу. В контексте ITIL Возврат инвестиций имеет несколько другое значение. Возврат инвестиций фактически является мерой возможного использования активов для увеличения ценности услуги. Приведем определение из официального глоссария ITILv3: Возврат инвестиции (Return on investment или ROI) - измерение ожидаемых выгод от инвестиций. В простейшем случае это чистая прибыль инвестиций, деленная на стоимость инвестированных активов [1]. Компании используют ROI для принятия решения относительно вложений в развитие сервисменеджмента, который сам по себе не несет явные тактические преимущества для бизнеса. ROI используется с позиции трех составляющих, входящих в любой проект - персонала компании, процессов и технологий. Далее производится их преобразование в количественные выходные параметры, соизмеримые с полезностью предлагаемых услуг и стоимостью их предоставления. Рассмотрение инвестиций в таком контексте значительно облегчает нахождение ожидаемых выгод и соответственно определение показателя ROI. Другим результатом такого подхода является создание разносторонних, с точки зрения знаний, кросс-функциональных команд, делящих между собой ответственность за успех проекта. В таком случае люди из разных подразделений работают вместе, и никто не может больше возложить ответственность только на IT, или наоборот, так как становится очевидной взаимоответственность людей[9]. В ITIL представлено три подхода ROI: • Бизнес-кейс - определение ключевых аспектов бизнеса, которые зависят от сервис-менеджмента. • Предпрограммный ROI - техники для количественного анализа инвестиций в сервис-менеджмент (исходя из названия, применяемые до инвестирования); • Постпрограммный ROI - техники для анализа инвестиций в сервис-менеджмент постфактум. 3.4.1. Бизнес-кейс Бизнес-кейс - обоснование какой-либо значительной статьи расходов. Включает информацию о затратах, выгоде, вариантах реализации, сложностях, рисках и возможных проблемах [1]. Фактически, бизнес-кейс является инструментом принятия решений и планирования, который прогнозирует наиболее вероятные результаты деятельности бизнеса. Результаты могут отображаться количественно и качественно. На рисунке представлена структура бизнес-кейса из публикации "Service Strategy": Рис. 3.10. Структура бизнес-кейса Цели бизнеса, как правило, определяются достаточно обобщенно. Выделяют следующие типы целей: 1. операционные: минимизировать риски, увеличить эффективность, увеличить производительность и т.п. 2. финансовые: избежать издержек, увеличить доходы от активов, увеличить выручку и т.п. 3. стратегические: представить конкурентоспособные продукты, улучшить удовлетворенность заказчиков, повысить качество и т.п. 4. отраслевые: улучшить позицию на рынке, занять лидирующую позицию на рынке и т.п. Если компания покупает услугу, она рассчитывает получить от нее поддержку осуществления поставленных целей. Внедренная услуга оказывает определенное влияние на бизнес, которое не имеет никакого значения без привязки к определенным бизнес-целям. 3.4.2. Пред-программный ROI Сервис-менеджмент в некоторых случаях требует долгосрочного финансового планирования. Составление бюджета долгосрочных расходов распадается на две большие категории: решения по отбору и решения по распределению привилегий. Решение по отбору предполагает принятие решения относительно того, пройдет ли предлагаемая сервис-менеджментом инициатива установленную границу, например, минимальный возврат вложений. На этом этапе определяется в целом, пригоден ли инвестиционный проект для дальнейшего рассмотрения. Решения по выбору предполагает ранжирование инвестиционных проектов и распределение привилегий. Есть два подхода для принятия решений относительно долгосрочных капиталовложений: • Чистый дисконтированный доход (Net Present Value (NPV)) - это сумма дисконтированных значений потока платежей, приведённых к сегодняшнему дню. Применим для принятия решений по отбору инвестиционных проектов. • Внутренняя норма доходности (Internal Rate of Return (IRR)) - это процентная ставка, при которой чистый дисконтированный доход (NPV) равен 0. Применим для принятия решений по распределению привилегий. Показатель NPV представляет собой разницу между всеми денежными притоками и оттоками, приведенными к текущему моменту времени (моменту оценки инвестиционного проекта). Он показывает величину денежных средств, которую инвестор ожидает получить от проекта, после того, как денежные притоки окупят его первоначальные инвестиционные затраты и периодические денежные оттоки, связанные с осуществлением проекта. Значение разницы двух потоков капиталовложения и прибыли - определяет, уместен ли данный инвестиционный проект: • если NPV имеет положительное значение, тогда предложенный инвестиционный проект приемлем. Более того, он экономически эффективен, так как обещает принести больше, чем требуемый процент возврата инвестиций. • если NPV равен нулю, тогда предложенный инвестиционный проект также приемлем. Он обещает принести прибыль, эквивалентную требуемому проценту возврата инвестиций. • если NPV имеет негативное значение, тогда предложенная программа инвестиций неуместна. Она принесет меньше требуемого процента возврата. Крупные компании обычно фиксируют обязательный процент возврата инвестиций. Это усредненная величина (в процентах или долях), которую компания должна заплатить пайщикам или кредиторам за использование их капиталов. Значение требуемого процента возврата инвестиций фактически является границей для принятия решений относительно рентабельности инвестиций. NPV плохо подходит для ранжирования инвестиционных проектов, то есть для принятия решений по привилегиям. Его можно применить только при условии одинаковых инвестиций, что на практике встречается крайне редко. Для принятия решений относительно ранжирования предложенных альтернатив лучше использовать IRR. Еще раз повторим, что IRR - это процентная ставка, при которой чистый дисконтированный доход (NPV) равен 0. Наиболее простой способ подсчета IRR: IRR=Требуемые инвестиции/Чистые ежегодные платежи. По полученному значению IRR вычисляется процент возврата ( с учетом заданного периода, обычно, 5 лет), который сравнивается с требуемым процентом возврата для данной компании. Если он меньше, то инвестиционный проект невыгоден. Таким образом, при принятии инвестиционных решений IRR используется для расчета процента возврата альтернативных инвестиций. При выборе из нескольких инвестиционных проектов с разными IRR, выбирается проект с максимальным значением IRR. 3.4.3. Постпроектный ROI Многие компании внедряют предложенные сервис-менеджметом решения без предварительного расчета выгодности инвестиций. Тем не менее, без четкого финансового определения желаемых целей и достигнутых результатов, они не могут измерить ценность, которую получили в результате инвестирования. Более того, на определенном этапе использования услуги могут потребоваться дополнительные вложения средств, и инвесторы захотят получить финансовое обоснование необходимости этих вложений. Постпроектный ROI предназначен для определения эффективности инвестиций после их вложения. На рис. 3.11представлена схема постпроектоного ROI. увеличить изображение Рис. 3.11. Схема постпроектного ROI Для начала необходимо определить цели инвестиционного проекта. Цели могут быть разными, например, "улучшить качество услуги", "внедрить лучшие производственные практики", "снизить совокупную стоимость владения" и т.п. Сбор данных является очень важным этапом расчета ROI, так как от него зависит корректность и точность полученного значения. Цели инвестирования помогают определить источники и природу необходимых данных. Например, параметры измерения качества услуги или анкеты для опроса клиентов об уровне их удовлетворенности. Далее результаты инвестиционного проекта должны быть изолированы. Используется несколько методов: 1. Прогнозирование. В данном методе чаще всего строится трендовая линия, чтобы спрогнозировать, что было бы, если бы анализируемый инвестиционный проект не был внедрен. Метод позволяет получить численные значения показателей. 2. Оценка влияния. Бывают случаи, когда прогнозирование использовать нельзя по причине отсутствия необходимых входных данных или сложности их измерения. Тогда применяется метод Оценки влияния. В простейшем случае, заказчики и инвесторы определяют уровень улучшений, принесенных внедрением инвестиционного проекта. 3. Контрольная группа. Техника подразумевает реализацию инвестиционного проекта в какой-то части организации. Полученная производительность сравнивается с другими частями организации, которые не участвовали в эксперименте[6]. Далее для того чтобы подсчитать ROI, полученные данные должны быть приведены к финансовым показателям. Техника приведения будет зависеть от конкретных данных. После получения количественной оценки результата, необходимо оценить совокупные вложения в проект. Они включают в себя: затраты на планирование, проектирование и реализацию, затраты на оборудование, затраты на обучение. Далее ROI вычисляется по одному из рассмотренных выше методов: NPV или IRR, в зависимости от ситуации. Таким образом, на этапе определения стратегии IT-организация выявляет ценность, которую может принести бизнесу, и продумывает, как эту ценность можно реализовать в виде конкретных услуг. Инструментом выявления услуг, которые могут принести ценность, является процесс Управления Портфелем услуг. Каталог услуг, которые поставщик может предложить в настоящее время, разработки новых услуг, улучшение существующих услуг, возможность передачи услуг на аутсорсинг и т.п. - всё это содержит в себе Портфель услуг, который отражает стратегию и потенциал IT-организации. При формировании стратегии поставщик услуг должен уделять внимание финансовой стороне: правильно сформировать ценность услуги, осознать и измерить полную стоимость предоставления услуги, понять, какую прибыль сможет получить он сам, инвесторы и заказчики. Лекция 4: Проектирование услуг как этап жизненного цикла услуг 4.1. Проектирование услуг как этап жизненного цикла В жизненном цикле услуг за этапом Построения стратегии следует Проектирование услуг. Основной целью этого этапа является проектирование новых услуг или внесение изменений в существующие услуги. Основные задачи в рамках Проектирования услуг: 1. проектирование услуг, которые способны помочь бизнесу в достижении запланированных результатов; 2. проектирование процессов, поддерживающих жизненный цикл услуг; 3. идентификация рисков и управление ими; 4. проектирование безопасности и отказоустойчивости IT-инфраструктур, оборудования, приложений, информационных ресурсов; 5. проектирование методов и метрик для измерений; 6. создание планов, процессов, политик, стандартов, архитектур и документов, которые будут способствовать проектированию качественных IT-решений, и управление ими; 7. развитие различных способностей и навыков в IT-области; 8. содействие улучшению качества услуг[10]. Требования для новых услуг формируются, как правило, на основе данных из Портфеля услуг и потребностей бизнеса. Проектирование услуг начинается с построения набора требований бизнеса и заканчивается разработкой решения, которое сможет удовлетворить эти требования и помочь бизнесу достичь запланированных результатов. Найденное решение вместе с проектной документацией переходит на этап Внедрения для запуска, тестирования или развития новой/измененной услуги. Проектная документация услуги (Service Design Package или SDP) - документы, определяющие все аспекты услуги и требования к ней на каждой стадии жизненного цикла [1]. Перед реализацией требования в проектной документации, оно должно быть проанализировано, формализовано и одобрено руководством. Не все изменения в жизненном цикле услуг требуют вовлечения деятельностей этапа Проектирования. Проектирование затрагивается, когда необходимы "значимые" изменения. Организация должна определить свой набор "значимых изменений", чтобы каждый сотрудник организации понимал, когда необходимо проектирование. Другими словами, абсолютно все изменения должны быть оценены со стороны "значимости" в контексте Проектирования. Такая оценка является частью процесса Управления изменениями. Разработанное на этапе Проектирования решение должно соответствовать политикам корпорации и IT. Поэтому при проектировании необходимо учитывать стратегии и ограничения, сформированные на этапе Построения стратегии. Интересно, что в ITIL выделено Четыре "П" для этапа Проектирования услуг, так же как и для этапа Построения стратегии: • персонал - люди, навыки и квалификация, включенные в обеспечение услуг; • продукты - технологии и системы управления, используемые для предоставления услуг; • процессы - процессы, роли и активности, включенные в обеспечение услуг; • партнеры - вендоры, поставщики и производители, которые обеспечивают поддержку и содействие в обеспечении услуг. Проектирование услуг в глобальном смысле является частью общего процесса изменения бизнеса. Процесс Изменения бизнеса и роль IT в нем изображен на рис. 4.1. увеличить изображение Рис. 4.1. Процесс Изменения бизнеса Основная роль Проектирования в контексте процесса изменения бизнеса заключается в разработке инновационных услуг (в том числе их архитектуры, процессов, политик и документации), которые смогут удовлетворить настоящие и будущие потребности бизнеса. При этом ключевые процессы ITSM должны быть применены в самом начале разработки новых услуг или внесения изменений в существующие. Ниже приведен набор действий, которые необходимо совершить на этапе Проектирования для того, чтобы разработанное решение эффективно удовлетворяло потребности бизнеса: 1. новое решение должно быть добавлено в Портфель услуг уже на стадии формирования концепции. Портфель услуг необходимо регулярно обновлять, дабы он отражал актуальный статус любых, даже самых незначительных, изменений в рамках инкрементального и итеративного развития. 2. В рамках начального анализа услуги/системы необходимо понять Требования к уровню услуг. Требование к уровню услуг (Service Level Requirements или SLR) - требование заказчика к IT-услуге. SLR(ы) базируются на бизнес-целях и используются для переговоров и согласования Целевых показателей уровня услуги[1]. 3. Используя SLR, команда Управления мощностями может смоделировать новую услугу с использованием имеющихся инфраструктур и понять, сможет ли она поддерживать эту услугу в дальнейшем. Если время позволяет, результаты моделирования отразятся в Плане обеспечения мощностей. План обеспечения мощностей (Capacity Plan) используется для управления Ресурсами, необходимыми для предоставления IT-услуг. Этот план содержит сценарии для прогнозирования спроса со стороны бизнеса, и оценку затрат, необходимых для обеспечения согласованных Целевых показателей уровня услуги[1]. 4. Если для обеспечения новой услуги или расширения поддержки имеющейся услуги требуются новые инфраструктуры, необходимо участие процесса Управления финансами. 5. Анализ влияния на бизнес и оценка рисков в отношении услуги должны быть проведены задолго до этапов Планирования мощностей, Проектирования доступности и формирования Стратегии обеспечения непрерывности. 6. Сервис-деск должен заранее готовиться к внедрению новых услуг, в частности, обучать свой персонал. 7. Этап Внедрения может начинать планирование реализации и построение расписания изменений. 8. Если новой услуге требуется дополнительное снабжение, необходимо вовлечение процесса Управления поставщиками. Управление поставщиками (Supplier Management) процесс, ответственный за обеспечение того, что договоры с поставщиками соответствуют требованиям бизнеса, и все поставщики выполняют свои контрактные обязательства[1]. Услуга и ее компоненты представлены на рис. 4.2. увеличить изображение Рис. 4.2. Услуга и ее компоненты Чтобы находить и создавать решения, которые смогут удовлетворить новые и существующие потребности бизнеса, проектирование услуг должно учитывать каждый из перечисленных ниже аспектов: 1. бизнес-процесс - определение функциональных потребностей, для которых предоставляется услуга (например, телепродажи или выставление счета-фактуры); 2. услуга - собственно, сама услуга, которая предоставляется бизнесу и потребителям. Например, электронная почта или хранение информации; 3. SLA/SLR: документы, согласованные с заказчиком, которые определяют уровень, охват и качество услуги; 4. инфраструктура - все оборудование, которое необходимо для предоставления услуги пользователям, включая сервера, маршрутизаторы, концентраторы, телефоны, компьютеры и т.п.; 5. окружающая среда - окружающая среда, необходимая для безопасной эксплуатации инфраструктуры: кондиционирование воздуха, электричество и т.п. 6. данные - данные, необходимые для поддержки услуги, а также для обеспечения бизнеспроцессов необходимой информацией (например, список клиентов, бухгалтерский регистр); 7. приложения - все программные приложения, необходимые для управления данными и обеспечивающие функциональные требования бизнес-процессов 8. поддерживающие услуги: любые дополнительные услуги, необходимые для предоставления услуги; 9. соглашения операционного уровня и контракты - любые соглашения, которые необходимы для предоставления услуги с качеством, согласованным на SLA; 10. службы поддержки - любые внутренние команды, обеспечивающие первую и вторую линию поддержки компонентов, необходимых для предоставления услуги, например, Unix или сети. 11. поставщики - любые внешние участники процесса, которые обеспечивают третью и четвертую линию поддержки компонентов, необходимых для предоставления услуги - сеть, аппаратное и программное обеспечение[10]. Проектирование должно рассматривать каждый из перечисленных выше аспектов в комплексе, а не изолированно. Чтобы в итоге получить конкурентоспособное решение, удовлетворяющее требованиям бизнеса, необходимо учитывать взаимосвязи и взаимозависимости указанных компонентов. При проектировании услуг под новые требования бизнеса следует учитывать не только функциональную составляющую этих требований. Предложенное на данном этапе решение должно обеспечивать бизнесу планируемую производительность. Делать всё необходимо с учетом имеющихся ресурсов, в установленных границах затрат и времени. Таким образом, менеджеры работают с тремя составляющими (рис. 4.3): • Функциональность: услуга, ее функциональные возможности, способности и качество. • Ресурсы: доступные люди, технологии и деньги. • Расписание: временные границы. Рис. 4.3. Три составляющих Проектирования Назначением Проектирования является соблюдение тонкого баланса трех составляющих с целью максимального удовлетворения потребностей бизнеса, которые постоянно изменяются. Изменение одной из трех составляющих влияет как минимум еще на одну, а то и на две оставшиеся. Чтобы разрабатывать эффективные решения, поставщикам услуг крайне важно понимать движущие факторы бизнеса и его потребности. Проектирование часто воспринимается только как стадия, предшествующая Эксплуатации. В ITIL подход несколько другой. Проектирование должно не только предложить эффективные решения, но и обеспечить возможность эффективного управления этими решениями в течение всего жизненного цикла. Если объединить всё вышесказанное, то целостный и правильный подход к проектированию должен предусматривать разработку услуг с механизмами и функциями управления и улучшения на всех этапах жизненного цикла. Люди, ответственные за управление Проектированием, должны убедиться в том, что обеспечено следующее: 1. наличие хорошей взаимосвязи между различными действиями в рамках проектирования и другими частями, в том числе планами и стратегиями IT и бизнеса; 2. доступность последних версий планов и стратегий бизнеса для тех, кто участвует в проектировании; 3. соответствие проектной документации планам и стратегиям бизнеса и IT; 4. архитектуры и дизайны: o гибки, а, следовательно, способны быстро реагировать на новые потребности бизнеса; o интегрированы со всеми стратегиями и политиками бизнеса и IT; o поддерживают потребности других стадий жизненного цикла услуги; o содействуют продвижению новых или измененных услуг, соответствующих потребностям бизнеса. Одним из подэтапов проектирования является определение и последующее документирование требований бизнеса и его драйверов. Под драйверами здесь понимается некие движущие бизнес-факторы: люди, информация и задачи, которые обеспечивают достижение поставленных целей. Для регулирования процессов проектирования информация делится на две категории: 1. Информация о требованиях к существующим услугам - какие изменения требуются в существующих услугах с учетом: o новых функциональных возможностей и требований; o изменений в бизнес-процессах, зависимостях, приоритетах, влиянии и критичности; o изменений в объеме транзакций услуги. Транзакция (Transaction) - дискретная функция, выполняемая ИТ-услугой. Например, перевод денег с одного банковского счета на другой. Одна Транзакция может содержать многочисленные добавления, удаления и изменения данных, при этом все они должны быть завершены успешно, в противном случае ни одна из них не должна быть выполнена (т.е. вся транзакция будет отменена); o повышением уровней услуги и целевых показателей уровня услуги в связи с новым драйвером у бизнеса, или понижение для старых услуг, которые будут в скором времени замещены; o потребностей в дополнительной информации процессов Управления услугами. 2. Информация о требованиях к новым услугам: o требуемая функциональность; o информация и другие потребности менеджмента; o поддерживаемый бизнес-процесс, зависимости, приоритеты, влияние и критичность; o требования уровня услуг и целевые показатели уровня услуг; o уровни транзакций бизнеса, уровни транзакций услуг, количество пользователей и его предполагаемый рост, типы пользователей; o финансовое и стратегическое обоснование для бизнеса; o предположение о будущих изменениях, то есть об известных будущих требованиях бизнеса или увеличение темпа роста. o уровень мощности для бизнеса, который должен быть представлен[10]. Это минимальный набор информации для начала проектирования. Ее точность и аккуратность первостепенна. Если некорректная и неправильная информация будет использована на этапе Проектирования, то разработанная услуга не будет удовлетворять потребностям бизнеса в конечном итоге. Требования к услугам должны быть документированы. Время, потраченное на это, будет компенсировано отсутствием в дальнейшем споров, дискуссий и разногласий между поставщиком услуг и заказчиком. Стадия определения требований бизнеса заключается в следующем: 1. назначение менеджера проекта, создание проектной команды и утверждение руководства с применением формальной и структурированной методологии; 2. идентификация всех заинтересованных лиц, составление соответствующих документов с их требованиями и выгодами, которые они получат в результате реализации проекта; 3. анализ, документирование, расстановка приоритетов и согласование требований. 4. вычисление и утверждение бюджета\выгод бизнеса; 5. разрешение потенциальных конфликтов между бизнес-единицами и соглашением о корпоративных требованиях; 6. определение процессов для утверждения требований и изменения утвержденных требований; 7. развитие плана взаимодействия с заказчиком, подчеркивание основных отношений между IT и бизнесом, и то, как эти отношения и необходимая связь с заинтересованными сторонами будет управляться[10]. После того, как требования согласованы и утверждены, у них появляется "ценник", то есть можно посчитать стоимостьконкретного проекта. Требуется соблюдать баланс между тем, что организация может себе позволить и тем, что она хочет. Реализация некоторых требований может слишком дорого стоить и они должны быть исключены уже на этапе Проектирования. При необходимости все решения об исключении требований к услугам могут быть документированы и согласованы с представителями бизнеса. Обычно сложности возникают при сопоставлении того, что хочет бизнес и бюджета, выделенного под решение, который не принимает в расчет полную стоимость услуги, в том числе расходы на текущее обслуживание. Применяемые документы при проектировании архитектуры и дизайны должны быть четкими, лаконичными, простыми и обоснованными. К сожалению, они часто слишком сложны и носят теоретический характер, а, следовательно, плохо применимы для практики в реальном мире. 4.2. Основные аспекты проектирования Выделяется пять ключевых аспектов Проектирования услуг: 1. проектирование решений, в том числе всех требуемых и согласованных функциональных требований, ресурсов и возможностей; 2. проектирование поддерживающих управленческих систем и инструментов, в частности Портфеля услуг для управления и контроля услуг в рамках их жизненного цикла; 3. проектирование технологий, систем и инструментов управления, необходимых для предоставления услуг; 4. проектирование процессов, необходимых для построения дизайна, внедрения, эксплуатации и улучшения услуг; 5. проектирование методов и метрик для измерения качества, эффективности и производительности услуг, архитектур и процессов. Конечно, ключевым аспектом проектирования является разработка решений, которые будут удовлетворять потребности бизнеса. Каждый раз при формировании новой услуги, она должна быть проверена по всем перечисленным выше пунктам. Это гарантирует то, что она сможет взаимодействовать и работать слаженно с другими услугами, которые уже находятся в эксплуатации. Рассмотрим подробнее ключевые аспекты Проектирования. 4.2.1. Проектирование решений Для проектирования новой услуги или внесения изменений в существующую услугу необходимо совершить много действий. В первую очередь нужен строгий и структурированный подход, который позволит создать решение с оптимальной стоимостью, функциональностью, качеством и в заданном временном интервале. Этот процесс и его составляющие показаны на рис. 4.4. Показан жизненный цикл услуги, от новых или измененных требований бизнеса до проектирования, внедрения и эксплуатации. Важным моментом здесь является связь между людьми, которые эксплуатируют услугу, и теми, кто ее проектирует. увеличить изображение Рис. 4.4. Создание услуг в соответствии с требованиями бизнеса Ниже приведены области, которые должны быть рассмотрены в ходе проектирования решения: 1. анализ требований бизнеса; 2. обзор и анализ существующих услуг и инфраструктур с целью выявления возможностей их использования в рамках нового решения 3. бизнес-циклы и сезонные колебания, связанные с ними уровни транзакций бизнеса и услуг, количество пользователей и его предполагаемый рост, типы пользователей. 4. Требования уровня услуг и Целевые показатели уровня услуг, а также необходимые действия по оценке, отчетности и обзору услуг. 5. временные рамки и планируемые результаты от использования услуги, а также ее влияние на существующие услуги. 6. требования к тестированию, в том числе User Acceptance Testing, а также ответственность за результаты тестирования. o убедиться, что Service Acceptance Criteria учтены и требуемые результаты включены в начальный дизайн. o рассмотреть и оценить существующие альтернативы, подчеркнуть их достоинства и недостатки o согласовать бюджет и издержки; o произвести повторную оценку и утверждение выгод для бизнеса, в том числе ROI. o согласовать выбранное решение и планируемые результаты от его использования. o проверить, соответствует ли выбранное решение принятым в корпорации и IT стратегиям, планам, политикам и проектировочным документам. Если нет, скорректировать либо решение, либо стратегию (или иной документ). Необходимо учитывать, что любое изменение стратегии влечет за собой колоссальные трудозатраты и должно быть сделано в рамках этапа Построения стратегии. o убедиться, что необходимый и доступный в рамках корпорации контроль за безопасностью включен в выбранное решение. завершить "оценку организационной готовности" IT, чтобы убедиться, что услугу смогут эффективно эксплуатировать, и организация имеет всё необходимое для обеспечения согласованного уровня услуги. Это включает в себя следующее: o 1. коммерческое влияние на организацию в целом от перспектив IT и бизнеса, в том числе все выгоды и сопутствующие расходы на разработку, проектирование, внедрение, а также операционные расходы, связанные с поддержкой услуги. 2. оценка и уменьшение рисков, связанных с внедрением решения 3. стойкость и зрелость бизнеса. Бизнес должен убедиться, что у него есть все необходимые процессы, структуры, роли, люди, возможности и ответственности , чтобы эксплуатировать новую услугу. 4. зрелость и стойкость IT. IT должна убедиться, что у нее есть необходимое оборудование, условия, персонал, ответственности, роли , документация и инструменты для предоставления и поддержки услуги. 5. соглашения с поставщиками, необходимые для обеспечения услуги 6. комплект проектной документации для последующего внедрения, эксплуатации и улучшения услуги. 4.2.2. Проектирование поддерживающих систем, в особенности Портфеля услуг Наиболее эффективным способом управления услугами в течение всего жизненного цикла является использование подходящих систем и инструментов управления. Основной системой управления является Портфель услуг, который описывает услугу, предоставляемую поставщиком, в терминах ценности для бизнеса. Он оперирует потребностями бизнеса и тем, что поставщик предлагает в ответ на них. Портфель услуг содержит детальную информацию о всех услугах и их статусе с отображением текущего этапа жизненного цикла (рис. 4.5). увеличить изображение Рис. 4.5. Портфель услуг - центральное хранилище информации ITIL рекомендует устанавливать услугам статусы, приведенные ниже: 1. "требования" - получен набор требований от бизнеса или IT для новой услуги или изменения существующей услуги; 2. "определена" - произведена оценка и документирование полученных требований, составлен SLR; 3. "проанализирована" - набор требований проанализирован и упорядочен; 4. "утверждена" - набор требований окончательно формализован и утвержден; 5. "наполнена" - выделены ресурсы и деньги для новой услуги; 6. "спроектирована" - новая услуга и ее компоненты спроектированы; 7. "разработана" - новая услуга и ее компоненты разработаны; 8. "собрана" - компоненты услуги компонуются вместе; 9. "тестирование" - услуга и ее компоненты тестируются; 10. "релиз" - релиз услуги и ее компонентов; 11. "эксплуатация" - использование услуги и ее компонентов; 12. "отстранена" - услуга и ее компоненты выведены из эксплуатации[10]. Различные элементы одной услуги могут иметь различные статусы в один момент времени. Каждая организация должна аккуратно проектировать Портфель услуг, его содержание и доступ к нему. Содержание Портфеля услуг должно включать в себя следующую информацию: 1. Имя услуги 2. Описание услуги 3. Статус услуги 4. Классификацию услуги и ее критичность 5. Используемые приложения 6. Используемые данные или/и схемы данных 7. Бизнес-процессы, поддерживаемые услугой 8. Владельцы бизнеса 9. Пользователи бизнеса 10. Владельцы IT 11. Уровень гарантии качества услуги, ссылки на SLA и SLR 12. Поддерживающие услуги 13. Поддерживающие ресурсы 14. Услуги, которые зависят от рассматриваемой услуги 15. OLA, контракты и соглашения 16. Затраты на услугу 17. Издержки на услугу (если это применимо в данном случае) 18. Доход от услуги (если это применимо в данном случае) 19. Метрики для услуги[10]. Заказчики и пользователи могут получить доступ к услугам только на стадиях между "наполнена" и "эксплуатация". Услуги с этими статусами содержатся в Каталоге услуг. Несмотря на то, что проектирование Портфеля услуг осуществляется на стадии проектирования, владеет и управляет им процесс Управления Портфелем услуг с этапа Построения стратегии. (Процесс Управление портфелем услуг принадлежит стадии жизненного цикла Построение стратегии. Проектирование конкретных услуг осуществляется на этапе Проектирования услуг, но процесс, который определяет основные моменты (Управление портфелем услуг) относится к этапу Построения стратегии. Стратегия Предприятия -> Портфель -> Услуги. В рамках построения Стратегии определяется состав Портфеля услуг, а затем уже осуществляется детальная разработка конкретных услуг. ) Портфель услуг является основным источником информации о требованиях и услугах, следовательно, проектировать его нужно очень аккуратно и последовательно. Аналогичный подход к проектированию требуют и другие системы управления, например, Service Knowledge Management System или Service Desk System. 4.2.3. Проектирование архитектур технологий Термин "архитектура" имеет различные трактовки в зависимости от контекста. Здесь архитектура - фундаментальная структура системы, отображающая ее компоненты, их взаимодействие друг с другом и условия эксплуатации системы, а также принципы, лежащие в основе проектирования и развития системы. Под "системой" здесь понимается не только системы в контексте IT. Система - совокупность компонентов, организованных для предоставления специфической функции или набора функций[10]. В качестве системы в данном контексте может рассматриваться организация в целом, бизнесфункция, информационная система и т.п. Сущность проектирования архитектур заключается в развитии и поддержке политик, стратегий, архитектур, дизайнов, документов, планов и процессов IT с целью развертывания и дальнейшей эксплуатации подходящих для организации услуг и решений. Входными данными для проектирования архитектур являются планы, стратегии и политики бизнеса и этапа Построения стратегии. Задачей проектировщиков является совершенствование и развитие дизайнов, планов, политик и архитектур. Этот процесс рассматривает также распределение ответственностей и ролей, услуги, технологии, архитектуры, процессы и процедуры, партнеров и поставщиков, методы управления. Проектирование архитектур также покрывает все вопросы в отношении технологий, в том числе инфраструктуру, окружение, приложения и данные. Как уже было отмечено выше, в качестве системы можно рассматривать организацию в целом. Организация является сложной системой с множеством компонентов: персонал, бизнес-функции, процессы, организационная структура, информационные ресурсы, финансовые ресурсы, стратегии, системы управления и т.п. Архитектура корпорации должна показывать, как эти компоненты взаимодействуют друг с другом для достижения общей корпоративной цели. ITIL рассматривает архитектуру корпорации в контексте бизнеса, который она ведет, и используемых информационных систем (рис. 4.6). Рис. 4.6. Архитектура корпорации Архитектура корпорации должна включать в себя следующие основные архитектуры: 1. Архитектура услуг - транслирует приложения, инфраструктуры, организацию и поддержку деятельностей в набор услуг. Архитектура услуг предоставляет независимый, интегрированный в бизнес подход для предоставления услуг бизнесу. Она предлагает модель для разделения между Архитектурой услуг, Архитектурой приложений, Архитектурой инфраструктуры и Архитектуры данных. В рамках Архитектуры услуг также рассматриваются вопросы обеспечения стойкости к сбоям, дальнейшей корректировки и обеспечения безопасности. 2. Архитектура приложений - предлагает детальный план по развитию и доставке индивидуальных приложений, отображает функциональные требования бизнеса к приложениям и показывает взаимозависимости между приложениями. Использование подхода, основанного на компонентах, максимизирует повторное использование и помогает приложениям быть гибкими в условиях изменяющихся политик снабжения. 3. Архитектура данных/информации - описывает логические и физические информационные активы организации и ресурсы управления ими. Она показывает, как распределены информационные ресурсы и управление ими для достижения корпоративной цели. 4. Архитектура инфраструктуры - описывает структуру, функциональность и географическое распределение программного и аппаратного обеспечения, компонентов коммуникации, а также относящиеся к ним стандарты. 5. Архитектура окружения - описывает аспекты, уровни и типы контроля окружения, а также их управления[10]. Взаимосвязь описанных архитектур показана на рис. 4.7. Рис. 4.7. Взаимосвязь архитектур 4.2.4. Проектирование процессов Процесс - структурированный набор действий, спроектированный для достижения специфической цели. Процесс преобразовывает один или несколько входов в определенные выходы. Определение процесса включает в себя все роли, распределение ответственности, инструменты и контроль, требующиеся для надежной доставки оговоренных результатов. Определенные однажды процессы должны контролироваться и быть управляемыми. Контроль процессов - деятельность, связанная с планированием и регулированием процесса, с целью представления процесса в эффективной, рациональной и стойкой манере. Только после определения уровней контроля, может быть определена система измерения эффективности контроля с соответствующими метриками (рис. 4.8). увеличить изображение Рис. 4.8. Элементы процесса Процесс всегда создается для достижения определенных целей. Выходы процесса должны напрямую зависеть от этих целей. При проектировании важным является разработка системы измерения и метрик для выходов процесса, системы отчетности и улучшения. У каждого процесса есть владелец, ответственный за процесс, его улучшение и то, что процесс обеспечивает достижение своих целей. Цели должны быть измеримы и описываться в терминах выгоды для бизнеса с учетом принятых политик и стратегий. На этапе Проектирования каждому процессу назначается владелец. Выходы процесса должны соответствовать некому набору операционных норм, источником которых являются цели бизнеса. Если результаты процесса соответствуют нормам, его можно назвать эффективным (потому что он может быть повторен, является измеримым и управляемым). Процесс также может быть назван эффективным, если он использует минимальный набор ресурсов. Результаты измерения и анализа процесса с соответствующими метриками должны отображаться в управленческих отчетах и поступать на вход процесса Непрерывного улучшения. Процесс является основой ITIL. Определение необходимых входов и выходов для процессов внутри организации дает возможность более эффективного и рационального управления ею. Установление норм для процессов позволяет измерить качество их работы. Нормы определяют конкретные условия, которым должны соответствовать результаты процесса. Определение норм дает основу процессу оценки качества процессов. Перед началом проектирования любого процесса важно представлять, как его выходы будут выглядеть. Каждая организация должна использовать формализованный подход для проектирования и реализации процессов сервис-менеджмента. Не нужно стремиться создавать "идеальные процессы". Важно проектировать практичные и приемлемые для данной организации процессы с встроенными в них механизмами улучшения. Одним из направлений развития процессного подхода является создание инструментов и стандартов, которые позволят осуществить интеграцию процессов, принадлежащих разным организациям. Примером является открытый стандарт DMTF, основанный на концепциях ITIL. Он формализует обмен информацией об инцидентах, проблемах и изменениях между процессами. 4.2.5. Проектирование методов и метрик для измерения Данная часть этапа Проектирования имеет большое значение, так как именно система измерения предоставляет информацию об эффективности услуги. Эта информация оказывает влияние на поведение людей, работающих с измеряемыми процессами, цели, производительность персонала и команды, а также оплату труда. Используемая система измерения и соответствующие ей метрики должны отражать качество и эффективность процессов проектирования с точки зрения бизнеса, заказчиков и пользователей. Она должна достоверно показывать способность услуги удовлетворять согласованным требованиям бизнеса. Есть четыре типа метрик, которые могут быть использованы для измерения производительности и возможностей процессов: 1. прогресс - измеренные в контрольных точках результаты процесса; 2. соответствие - соответствие процесса требованиям руководства и регуляторов. 3. результативность - аккуратность, корректность процесса, а также его способность достигать поставленные цели. 4. эффективность - мера целесообразности использования ресурсов для реализации процесса. Для незрелого процесса лучше подходят первые две метрики, для зрелого процесса рекомендуется определять эффективность и результативность. 4.3. Дальнейшие действия в рамках Проектирования услуг Прежде чем передать спроектированное решение на этап Внедрения, необходимо выполнить ряд дополнительных действий: 1. Оценка альтернативных решений. Эта деятельность необходима, если к предоставлению услуг привлечены внешние поставщики услуг и решений. Состоит из следующего: o формирование набора поставщиков и организация тендера; o обзор и оценка всех решений, предлагаемых поставщиками. Отбор наиболее подходящих для конкретной задачи поставщиков; o оценка и расчет стоимости альтернатив, с последующим выборов наилучших. 2. Снабжение выбранного решения Хотя существует возможность, что для разработанного решения не потребуется участие третьих сторон (то есть поставщиков), тем не менее, на практике чаще всего они участвуют, а, следовательно, необходимо выполнить следующее: o завершение всех необходимых проверок выбранного поставщика; o заключение контрактов с поставщиком; o снабжение выбранного решения. 3. Разработка решения. Сюда относится деятельность по трансляции проекта услуги в план по ее разработке. Каждый план будет ответственен за разработку одного или более компонентов услуги и должен включать следующее: o потребности бизнеса; o стратегия, применяемая для разработки и/или приобретения решения; o временные рамки; o требуемые ресурсы, в том числе возможности и инфраструктуры IT, квалифицированный персонал и т.п.; o разработка услуги и ее компонентов, в том числе механизмов управления, формирования отчетности, измерения и т.п. o план тестирования услуги и ее компонентов. 4.4. Модели для проектирования и предоставления услуг Модель для проектирования услуг зависит от модели их предоставления. То есть перед тем, как выбрать модель для проектирования новой услуги, необходимо провести обзор текущих возможностей и резервов для ее предоставления. Такой обзор должен включать в себя следующие вопросы: • требования и драйверы бизнеса; • охват и возможности поставщика услуг; • спрос, цели и требования к новой услуге; • охват и возможности внешних поставщиков; • силы организаций, которые уже задействованы; • культурные особенности вовлеченных в процесс организаций; • задействованные инфраструктуры, приложения, данные, услуги и другие компоненты IT; • степень требуемого контроля со стороны руководства; • доступные ресурсы и финансовые средства; • уровень персонала и необходимые навыки[10]. Информация, полученная из такого обзора поставщика услуг, поможет понять, как он предоставляет услуги и какие возможности может задействовать в отношении новой спроектированной услуги. Модель предоставления услуг даст основу для выбора модели проектирования услуг. Существует много моделей для предоставления услуг, каждая из которых имеет свои преимущества и недостатки. В табл. 4.1представлены основные модели предоставления услуг. На практике предоставление услуг происходит по одной из представленных моделей или ее вариации. Таблица 4.1. - Модели предоставления услуг Использование внутреннего поставщика услуг для Инсорсинг(Insourcing) управления ИТ-услугами[1]. Организация использует внутренние ресурсы для проектирования, разработки, внедрения, управления, эксплуатации и(или) поддержки новых, измененных или пересмотренных услуг. Аутсорсинг(Outsourcing) Использование Внешнего поставщика услуг для управления ИТ-услугами[1]. Организация использует ресурсы внешней организации(или организаций) для осуществления части деятельности, связанной с проектированием, разработкой, управлением, эксплуатацией или поддержкой услуг. Ко-сорсинг (Co-sourcing) Комбинирование инсорсинга и аутсосинга. Используется ряд внешних организаций для обеспечения каких-то отдельных элементов в рамках жизненного цикла услуг. Сотрудники организации-заказчика и сторонней организации работают вместе для проектирования, разработки, внедрения, управления, эксплуатации и(или) поддержки новых, измененных или пересмотренных услуг. Например, на аутсорсинг может быть отдана часть разработки программного обеспечения, в то время как основным кодом будет владеть сам заказчик. Партнерство или Подход предусматривает формальное соглашение двух и мультисорсинг (Partnership or более организаций на проведение совместных работ по multisourcing) проектированию, разработке, внедрению, управлению, эксплуатации и(или) поддержке услуг. Аутсорсинг бизнес-процессов Подход предусматривает передачу целого бизнес-процесса (Business Process Outsourcing) организации-заказчика на аутсорсинг другой организации через заключение соглашения. Например, передача бухгалтерского учета. Предоставление услуг Подход предусматривает заключение соглашений с прикладного уровня Поставщиками услуг прикладного ПО. Поставщик услуг (Application Service Provision) прикладного ПО (Application Service Provider или ASP) внешний поставщик услуг, который предоставляет услуги с использованием приложений, развернутых на мощностях провайдера. Пользователи получают доступ к приложениям посредством сетевого подключения к провайдеру[1]. Аутсорсинг управления KPO является новейшей формой аутсорсинга. По сути, знаниями (Knowledge является стадией, предшествующей аутсорсингу целых Process Outsourcing или KPO) бизнес-процессов. В данном случае организация-заказчик передает внешней организации процессы, которые требуют специфических опыта, квалификации и навыков. Например, тренинг сотрудников. KPO предполагает управление процессами, которые требуют глубокого изучения или серьёзной аналитической обработки данных, формирования и управления базами знаний, которые в последующем могут использоваться, в том числе и для поддержки принятия решений. Аутсорсинг позволяет компании-заказчику сократить издержки и значительно снизить трудоёмкость и затраты на эксплуатацию информационных систем и приложений, сконцентрироваться на основных бизнес-процессах компании, не отвлекаясь на вспомогательные[11]. К основным выгодам аутсорсинга можно отнести: • снижение стоимости реализации бизнес-процесса за счет использования ресурсов сторонней организации, • увеличение качества получаемых продуктов и услуг за счет использования специфических ресурсов и знаний сторонней организации или за счет того, что организация-заказчик сможет не отвлекаться на вспомогательные бизнес-процессы. ITIL выделяет два подхода к разработке программного обеспечения и услуг: 1. традиционное проектирование - так называемая, каскадная модель (от англ. waterfall). Модель проектирования, в которой процесс разработки выглядит как поток, последовательно проходящий фазы анализа требований, проектирования, реализации, тестирования, интеграции и поддержки[12]. 2. RAD (от англ. rapid application development - быстрая разработка приложений) - концепция создания средств разработки программных продуктов, уделяющая особое внимание быстроте и удобству программирования, созданию технологического процесса, позволяющего программисту максимально быстро создавать компьютерные программы. Практическое определение: RAD - это жизненный цикл процесса проектирования, созданный для достижения более высокой скорости разработки и качества ПО, чем это возможно при традиционном подходе к проектированию[5]. В каскадной модели стадии идут в следующем порядке: • Определение требований • Проектирование • Конструирование (также "реализация" либо "кодирование") • Интеграция • Тестирование и отладка (также "верификация") • Инсталляция • Поддержка При этом разработчик не может перейти к следующей стадии, не закончив предыдущую. Сначала полностью завершается этап "определение требований", в результате чего получается список требований к программному обеспечению. После того как требования полностью определены, происходит переход к проектированию, в ходе которого создаются документы, подробно описывающие для программистов способ и план реализации указанных требований. После того как проектирование полностью выполнено, программистами выполняется реализация полученного проекта. На следующей стадии процесса происходит интеграция отдельных компонентов, разрабатываемых различными командами программистов. После того как реализация и интеграция завершены, производится тестирование и отладка продукта; на этой стадии устраняются все недочёты, появившиеся на предыдущих стадиях разработки. После этого программный продукт внедряется и обеспечивается его поддержка - внесение новой функциональности и устранение ошибок[12 ]. Плюсом каскадной модели является возможность заранее посчитать стоимость реализации решения, основным недостатком же - отсутствие гибкости и возможности быстро реагировать на изменяющиеся потребности бизнеса. На рис. 4.9 представлено сравнение RAD и каскадного метода. Рис. 4.9. Сравнение RAD и Каскадного метода RAD является более современным и гибким подходом к проектированию. Основным преимуществом RAD является применение итеративного и инкрементального подхода к разработке решений. Итеративный подход предполагает выполнение работпараллельно с непрерывным анализом полученных результатов и корректировкой предыдущих этапов работы, то есть своего рода обратную связь. Проект при этом подходе периодически проходит повторяющийся цикл Планирование-Реализация-Проверка-Оценка. Благодаря применению итеративного подхода, RAD может быстро реагировать на изменяющиеся требования бизнеса. Инкрементальный подход предполагает разработку услуги "от куска к куску", то есть последовательно. При этом каждый "кусок" может поддерживать одну из бизнес-функций, для которых предназначена услуга в целом. Для бизнеса инкрементальный подход дает возможность использования какой-то значимой части услуги до того,как она будет разработана полностью. При проектировании услуг возможно комбинирование инкрементального и итеративного подходов. Начинают с определения требований для услуги в целом, продолжают путем инкрементальной разработки отдельных ее частей. В целом RAD имеет следующие преимущества перед традиционным подходом: 1. продукт быстрее поступает на рынок; 2. более широкие возможности для разработки устраивающего пользователей интерфейса; 3. большая адаптивность к изменяющимся требованиям бизнеса; 4. простота развития и изменения функциональности решения. Еще одним подходом является покупка готовых решений, так называемых "off-the-shelf" или COST. При покупке такого программного обеспечения организация должна: 1. понимать достоинства и недостатки этого подхода; 2. формализовать процесс выбора наиболее эффективного готового решения; 3. определить процесс для эффективной интеграции и настройки готового решения; 4. определить функциональные требования на приемлемом уровне; 5. сформировать перечень управленческих и операционных требований; 6. определить требования к продукту и поставщику; 7. определить требования к интеграции услуги. Покупка готовых пакетов программного обеспечения более экономична, но менее гибка, чем разработка собственных решений. Тем не менее, в ряде случаев организации легче и экономически выгоднее купить готовое решение. Лекция 5: Процессы в рамках этапа Проектирования: Управление Каталогом услуг, мощностями и доступностью Аннотация: Процессы и деятельности в рамках этапа Проектирования услуг: Управление Каталогом услуг, Управление уровнем услуг, Управление мощностями и Управление доступностью. Для каждого процесса рассматривается цель, входы и выходы, основные деятельности и ключевые показатели эффективности. Ключевые слова: информация, интеграция, цикла, деятельность, бизнес-процессы, служба каталогов, значение, представление, ITIL, доступ, SLM, мониторинг, требования заказчика, очередь, портфель, корректность, достоверность, SLA, SLR, механизмы, целостность, ме сто, PIR, улучшение, пропускная способность, единица, мощность, поддерживающая инфраструктура, транзакция, workload, точность прогноза, количество информации, надежность, производительность, безопасность, определение, анализ, инфраструктур а, процесс управления, MTBF, AMIS Конечной целью этапа Проектирования является создание услуг, которые способны удовлетворить изменяющиеся потребности бизнеса. На вход Проектирования поступает информация от различных источников. Для создания эффективных услуг она должна быть собрана, проанализирована, а также переоценена и пересмотрена в терминах проектирования. Такая интеграцияпроектирования с другими областями и этапами жизненного цикла услуги гарантирует, что новые решения будут совместимы и сравнимы с уже существующими услугами и смогут оправдать ожидания пользователей и заказчиков. В "Процессы в рамках этапа Проектирования: Управление Каталогом услуг, мощностями и доступностью" и "Управление непрерывностью услуг и информационной безопасностью в рамках этапа Проектирования. Управление поставщиками" мы рассмотрим процессы, ответственные за предоставление информации, необходимой для проектирования новых или измененных услуг. 5.1. Управление Каталогом услуг Каталог услуг является ключевым источником информации об услугах, предоставляемых бизнесу поставщиком услуг. Он предоставляет бизнесу актуальную, достоверную и целостную картину о доступных услугах, их деталях и статусах. Целью Управления Каталогом услуг является управление информацией, содержащейся в Каталоге услуг, гарантия того, что она корректна и отражает актуальные статусы, детали и зависимости всех услуг, которые эксплуатируются или готовы к эксплуатации. Задачей Управления Каталогом услуг является формирование Каталога услуг и управление им. Деятельность в рамках Управления каталогом услуг должна включать следующее: 1. определение услуг; 2. формирование и поддержка Каталога услуг; 3. обеспечение связи, зависимости и согласованности Портфеля услуг и Каталога услуг; 4. обеспечение связей и зависимостей между всеми услугами, поддерживающими их компонентами и конфигурационными единицами в контексте Каталога услуг и Системы управления конфигурациями. Конфигурационная единица (Configuration Item или CI) любой компонент, который нуждается в управлении для того, чтобы предоставлять услугу[1]. Информация о каждой конфигурационной единице регистрируется в форме записи в Системе управления конфигурациями и поддерживается актуальной в течение всего жизненного цикла процессом Управления конфигурациями. Каталог услуг имеет особую ценность для бизнеса, так как предоставляет актуальную информацию о доступных услугах поставщика, в том числе о том, как они предоставляются, какие бизнеспроцессы поддерживают и какое качество гарантируют. Политика, принятая и поддерживаемая в организации, должна рассматривать вопросы, связанные с Каталогом услуг и Портфелем услуг. В частности, определять детали услуг, необходимые для отображения в Каталоге и Портфеле услуг, и перечень статусов, которые могут иметь услуги. Важным аспектом политики является распределение ответственности за каждую часть Портфеля услуг. Понятие самой услуги варьируется в зависимости от того, кто ее использует. Так, пользователи могут не видеть и, следовательно, не учитывать некоторые вспомогательные услуги. Вспомогательная услуга - услуга, обеспечивающая или дополняющая работу базовой услуги. Например, служба каталогов - основная услуга, и услуга резервного копирования вспомогательная. Для IT вспомогательные услуги имеют большое значение, так как они дают возможность предоставлять "видимые" для пользователей услуги и обеспечивать их качество. Поэтому вспомогательные услуги обязательно должны быть отображены в Каталоге услуг. Рекомендуемой практикой является иерархическое представление услуг в Каталоге услуг с детализацией типа услуг - бизнес-услуга, поддерживающая услуга, распределенная услуга и т.п. Каталог услуг имеет две составляющие: 1. Каталог услуг для бизнеса - представляет взгляд заказчика на Каталог услуг. Он содержит информацию обо всех услугах, предоставляемых заказчику, их взаимосвязи с бизнесединицами и бизнес-процессы, для поддержки которых они предназначены. 2. Технический Каталог услуг - это та часть Каталога услуг, которая не видна пользователям. Содержит информацию обо всех услугах, предоставляемых заказчикам, а также их связи с поддерживающими и распределенными услугами, компонентами и конфигурационными единицами. Взаимодействие двух составляющих Каталога услуг представлено на рис. 5.1. увеличить изображение Рис. 5.1. Взаимосвязь Каталога услуг для бизнеса и Технического каталога услуг Как показывает рис. 5.1 Каталог услуг для бизнеса связывает услуги и бизнес-процессы, то есть то, что волнует бизнес, а Технический Каталог услуг связывает услуги с тем, что обеспечивает их работу, то есть то, что волнует IT. Действия, которые должны быть предприняты в рамках Управления Каталогом услуг: 1. Утверждение и документирование всех услуг вместе с компонентами, относящимися к ним; 2. Взаимодействие с Управлением Портфелем услуг с целью согласования информации, содержащейся в Портфеле услуг и Каталоге услуг; 3. Формирование и поддержка Каталога услуг с привязкой к Портфелю услуг; 4. Взаимодействие с IT и бизнесом с целью установления зависимостей между бизнесединицами с их бизнес-процессами и поддерживающими услугами. 5. Взаимодействие со службами поддержки, поставщиками и Управлением конфигурациями с целью установления зависимостей между услугами и поддерживающими компонентами, содержащимися в Техническом Каталоге услуг. 6. Взаимодействие с Управлением взаимоотношений с бизнесом и Управлением уровнем услуг с целью гарантии того, что информация в Каталоге услуг корректируется в соответствии с бизнесом и его процессами[10]. Информация для организации Управления Каталогом услуг поступает из различных источников. В ITIL источники информации для процесса называются входами. Основными входами процесса Управления услуг являются: 1. стратегии и планы бизнеса и IT, текущие и будущие требования к Портфелю услуг; 2. влияние, приоритеты и риски, связанные с каждой услугой или с изменением требований к ней. Эту информацию предоставляет процесс Анализа влияния на бизнес; 3. требования бизнеса - детальное описание новых или измененных требований бизнеса к Портфелю услуг; 4. Портфель услуг; 5. Система управления конфигурациями (CMS); 6. обратная связь с другими процессами в рамках жизненного цикла услуги. Выходами Управления Каталогом услуг являются: 1. утвержденная руководством документация, описывающая услуги; 2. обновления Портфеля услуг, в результате которых в нем будет содержаться актуальная информация о статусах и зависимостях услуг; 3. Каталог услуг, который содержит детальное описание текущих статусов услуг, вместе с описанием интерфейсов и зависимостей. Ключевой показатель производительности (Key Performance Indicator или KPI) метрика, которая используется для управления процессом, услугой или деятельностью. Выделяется два Ключевых показателя производительности в контексте Управления Каталогом услуг: o Процентное соотношение количества услуг, которые содержатся в Каталоге услуг, к количеству услуг, которые предоставляются заказчикам в определенный момент времени. o Количество расхождений между информацией, содержащейся в Каталоге услуг, и "реальной ситуацией". Основными рисками для Управления Каталогом услуг является неточная информация, поступающая от бизнеса и IT, а также плохо организованный доступ к Каталогу услуг. 5.2. Управление уровнем услуг Управление уровнем услуг (Service Level Management или SLM) - процесс, ответственный за обсуждение Соглашений об уровне услуг, и гарантирующий их выполнение. SLM ответственен за то, что процессы Управления услугами, соглашения операционного уровня и внешние договоры будут соответствовать согласованным целевым показателям уровня услуги. SLMотслеживает и отчитывается по Уровням услуг, выполняет регулярные обзоры для заказчиков[1]. Другими словами, процесс отвечает за переговоры с заказчиками, согласование требований и постановку значений различных показателей, к которым должна стремиться услуга - целевым показателям уровня услуги. Производится мониторинг процесса и формирование отчетности, в которой отражается способность поставщика услуг выполнять требования заказчика. Успех SLM во многом зависит от предоставленной информации, на основании которой формируются целевые показатели. Источниками информации в первую очередь являются Каталог услуг и Портфель услуг. SLM является своего рода точкой взаимодействия поставщика услуг и заказчика. Он должен представлять поставщика услуг бизнесу и бизнес - поставщику услуг. SLM обеспечивает корректность, профессиональность и достоверность методов, применяемых для измерения производительности услуг. Промежуточные цели процесса Управления уровнем услуг: 1. определение, согласование и документирование уровня предоставляемых услуг; 2. обеспечение и улучшение взаимоотношений заказчиков и поставщиков; 3. обеспечение того, что целевые значения для услуг достижимы и их можно измерить; 4. мониторинг и улучшение удовлетворенности заказчиков уровнем предоставляемых услуг; 5. гарантия того, что заказчики имеют четкое и недвусмысленное ожидание уровня услуги; 6. гарантия того, что используются проактивные методы измерения там, где это экономически оправдано. SLM должен включать следующее: • развитие взаимоотношений с бизнесом; • переговоры и согласование требований и целевых показателей, а также документирование и управление SLA для всех услуг, находящихся в промышленной эксплуатации. • развитие и управление OLA, чтобы обеспечить соответствие и корреляцию с SLA. • пересмотр и анализ контрактов с поставщиками и других соглашений в рамках Управления поставщиками, чтобы обеспечить корреляцию с SLA. • предупреждение отказов, уменьшение рисков, улучшение качества услуг; • управление и отчетность по всем услугам, обзор всех слабостей и "брешей" SLA; • координация Плана совершенствования услуг. План совершенствования услуг (Service Improvement plan) - формальный План для внедрения улучшений в процесс или услугу[1]. SLA является основой для формирования отношений между бизнесом и поставщиком услуг, а SLM точкой взаимодействия. Основная деятельность в рамках SLM должна включать следующее: 1. документирование, согласование, утверждение требований заказчиков в форме SLR и управление ими в рамках жизненного цикла услуги с помощью SLA; 2. мониторинг и измерение производительности услуг в рамках SLA; 3. измерение и мониторинг пользовательской удовлетворенности; 4. формирование отчетности; 5. сбор и анализ информации, полученной из отчетов; инициирование улучшений в рамках Плана совершенствования услуг; 6. обзор и проверка SLA, OLA, контрактов и других базовых соглашений; 7. развитие и документирование контактов и взаимоотношений с инвесторами, заказчиками и бизнесом; 8. регистрация всех положительных и отрицательных отзывов; 9. предоставление корректной информации в рамках содействия Управлению производительностью и демонстрации достижений услуг; 10. обеспечение доступности/актуальности документов и стандартов SLM, а также управление ими. Используя Каталог услуг SLM должен сформировать наиболее приемлемый для конкретной организации SLA. Выделяют несколько типов SLA. 1. SLA, основанный на услугах - это SLA, описывающий один тип услуг для всех пользователей этой услуги. Например, SLA может покрывать услугу электронной почты для всех ее пользователей. Преимуществом данного подхода является его простота. Недостатком то, что разным типам пользователей может потребоваться разный уровень услуги или же они могут иметь различные преимущества с точки зрения инфраструктуры. Например, топ-менеджеры могут быть подключены к быстрым сетям, рядовые сотрудники - к более медленным. Другими словами, необходимо объединить разные целевые показатели внутри одного соглашения. 2. SLA, основанный на пользователях - это SLA, описывающий все услуги, которые использует определенная группа пользователей. Например, SLA может описывать все услуги, предоставляемые финансовому отделу корпорации. Этот вид SLA наиболее удобен для заказчика, так как покрывает все услуги, которые ему необходимы. 3. мультиуровневый SLA(рис. 5.2), например, может включать три уровня. o уровень корпорации - покрывает базовые особенности SLM, подходящие для каждого сотрудника организации. Эти особенности должны быть наиболее постоянны, так как обновлять SLA на этом уровне очень сложно; o уровень пользователей - покрывает все особенности SLM, относящиеся к конкретной группе пользователей или бизнес-единице в части используемых ими услуг; o уровень услуг - покрывает все особенности SLM, относящиеся к конкретной услуге в отношении конкретной группы пользователей[10]. Рис. 5.2. Мультиуровневый SLA Многоуровневая структура позволяет избавиться от дублирования информации и лишних обновлений. Какую бы структуру ни выбрали поставщики услуг и бизнес, формулировки SLA должны быть четкими и не оставлять никаких сомнений. После того, как форма SLA утверждена, должен быть сформирован SLR. Этот процесс достаточно сложен ввиду того, что бизнес чаще всего не может сформулировать однозначно свои желания и потребности в терминах производительности, безопасности, мощности и непрерывности услуг. С крупными заказчиками ведутся длительные переговоры с целью построения SLR и нахождения баланса между тем, что хочется, и тем, что можно обеспечить исходя из объективных факторов. После утверждения SLR и SLA должны быть разработаны механизмы для мониторинга производительности услуги. Плохо разработанные механизмы приводят к непониманию и спорам между заказчиком и поставщиком, в результате чего весь процесс SLM теряет смысл. Важно следить за всеми компонентами услуги, так как для заказчика важна ее целостность, постоянство и доступность в любое время. Пользователи в свою очередь должны незамедлительно сообщать поставщику обо всех инцидентах и проблемах, чтобы он мог внести необходимые коррективы в услугу и ее компоненты. Измерение пользовательской удовлетворенности отлично от измерения производительности, которую можно и нужно максимально автоматизировать. Пользовательская удовлетворенность является субъективным фактором. Даже если пользователи сталкиваются со сбоями услуги, они при этом всё равно могут иметь о ней позитивное впечатление, и наоборот. С самого начала необходимо попытаться управлять ожиданиями заказчиков. Это означает постановку надлежащих ожиданий и соответствующих целевых показателей на первое место, и дальнейшую разработку систематического процесса на управление ими. Удовлетворенность пользователей = восприятие - ожидания. Если это значение нулевое или больше нуля, то заказчик удовлетворен. Чтобы измерить восприятие заказчика ITIL рекомендует следующие методы и средства: 1. периодические опросы и анкетирование заказчиков; 2. обратная связь с пользователями посредством встреч; 3. обратная связь от Обзора результатов внедрения. Обзор результатов внедрения является частью процесса Управления изменениями. Обзор результатов внедрения (Post Implementation Review или PIR) - обзор, выполняемый после внедрения изменения проекта. Он определяет успешность изменения проекта и выявляет возможности для улучшения[1]. 4. телефонный опрос заказчиков; 5. отзывы пользователей, оставленные по их инициативе; 6. форумы; 7. анализ достоинств и недостатков. Для поставщика услуг важно показать заказчикам то, что он внимательно относится к их мнению и вносит соответствующие коррективы и улучшения в предоставляемые услуги. Поставщик услуг всегда зависит от некоторых своих или внешних служб поддержки, поставщиков или внешних партнеров. Контракты с внешними поставщиками являются необходимостью, но многие поставщики заключают также соглашения с внутренними группами поддержки Соглашения операционного уровня. Соглашение операционного уровня (Operational Level Agreement или OLA) - cоглашение между поставщиком услуг и другой частью той же организации. OLA поддерживает поставщика услуг в предоставлении услуг заказчикам. OLA определяет предоставляемые товары или услуги и ответственность обеих сторон[1]. Перед тем, как формировать новый SLA или вносить в него изменения, необходимо пересмотреть существующие соглашения операционного уровня и, при необходимости, обновить их. Как только SLA сформирован и разработаны механизмы мониторинга, необходимо отладить процесс формирования отчетов. Отчеты должны формироваться регулярно - еженедельно или даже чаще. Расписание и формат отчетов необходимо согласовать с заказчиками. Отчеты должны быть понятны и содержать информацию о производительности услуги в контексте целевых показателей, оговоренных в SLA, а также информацию обо всех изменениях и улучшениях. ITIL рекомендует устраивать регулярные встречи с заказчиками с целью обзора предоставляемых услуг и их достижений за последний период. Такие "обзорные встречи" необходимо проводить раз в месяц или хотя бы в квартал. Представители заказчика и поставщика услуг должны рассматривать отчеты о функционировании услуги, выявлять места, где показатели не достигают установленных целевых значений, и договариваться о дальнейших улучшениях услуг. Множество факторов может послужить триггерами для SLM, в частности: 1. изменения в Портфеле услуг, такие как новые требования бизнеса, новые или измененные услуги; 2. новые или измененные соглашения, SLR, SLA, OLA и т.п. 3. "обзорные мероприятия"( анкетирование, встречи, телефонные опросы и т.п.); 4. нарушения в услуге; 5. положительные или отрицательные отзывы; 6. изменения в стратегии или политиках. Входами для SLM являются: • информация от бизнеса - стратегии, планы, текущие и будущие требования; • Анализ влияния на бизнес - информация о влиянии, приоритетах, рисках и количестве пользователей по каждой услуге; • требования бизнеса - детали о любых согласованных новых или измененных требованиях бизнеса; • стратегии, политики IT и ограничения с этапа Построения стратегии; • Портфель услуг и Каталог услуг; • информация об изменениях - информация от процесса Управления изменениями; • CMS - информация о взаимодействии бизнес-услуг, вспомогательных услуг и технологиях. • обратная связь с заказчиками, положительные и отрицательные отзывы. Выходами SLM являются: • отчеты об услугах, которые предоставляют информацию о работе услуги в контексте целевых показателей SLA. Эти отчеты должны содержать детальную информацию обо всех сторонах услуги и ее предоставления, включая текущую и прошлую производительность, слабости и "бреши", основные события, запланированные изменения, текущий и будущий объем работы, планы и деятельность по улучшению. • План совершенствования услуг (SIP); • шаблоны документов для составления SLA, SLR, OLA и других соглашений; • SLA; • SLR; • OLA. ITIL выделяет субъективные и объективные индикаторы производительности SLM. К субъективным относится улучшениеудовлетворенности заказчиков предоставляемыми услугами. К объективным: • количество или процент достигнутых целевых показателей; • количество "брешей" в услугах; • количество услуг с актуальными SLA; • количество услуг с регулярно формируемыми отчетами и обзорами. Подводя итог, можно сказать, что SLM является "шпионом в обоих лагерях". Он налаживает взаимодействие поставщиков и заказчиков, представляя то одну, то другую сторону. При представлении "оппозиционной" точки зрения на встречах, переговорах и т.п. часто возникает обоюдное раздражение и непонимание. Поэтому SLM должен быть максимально открытым и полезным в своем взаимодействии с обеими сторонами - поставщиком услуг и заказчиком. 5.3. Управление мощностями Управление мощностями (Capacity Management) - процесс, отвечающий за своевременное и эффективное по затратам соответствие мощности услуг и инфраструктуры требованиям согласованных целевых показателей уровня услуги. Управление мощностями принимает во внимание все ресурсы, необходимые для предоставления услуг, а также производит краткосрочное, среднесрочное и долгосрочное планирование бизнестребований. Мощность(Capacity) - максимальная пропускная способность, которую может обеспечить конфигурационная единица или услуга в рамках согласованных целевых показателей уровня услуги. Для некоторых типов конфигурационных единиц, мощность может быть выражена размером или объемом, например, жесткого диска[1]. Промежуточные цели Управления мощностями: • формировать План обеспечения мощностей и управлять им. План обеспечения мощностей (Capacity Plan) - план обеспечения мощностей используется для управления ресурсами, необходимыми для предоставления услуг[1]. Этот план содержит сценарии для прогнозирования спроса со стороны Бизнеса, и оценку затрат, необходимых для обеспечения согласованных Целевых показателей уровня услуги; • предоставлять рекомендации и руководства для всех других областей бизнеса и IT по всем вопросам, связанным с производительностью и мощностью; • контролировать, чтобы услуги достигали установленных целевых показателей, путем управления производительностью и мощностью, как услуг, так и ресурсов; • содействовать в диагностировании и разрешении проблем, связанных с производительностью и мощностью; • оценивать влияние изменений на План обеспечения мощностей, услуги и ресурсы; • гарантировать, что проактивные средства улучшения производительности внедрены там, где это экономически оправдано. Управление мощностями включает в себя следующие деятельности: 1. мониторинг моделей бизнеса-деятельностей и планов на уровне услуг в терминах производительности использования пропускной способности IT-услуг и поддерживающих инфраструктур, окружения, данных, приложений. Процесс должен формировать случайные и регулярные отчеты о производительности и мощности услуг и их компонентов; 2. проведение деятельности по регулировке и настройке с целью максимально эффективного использования ресурсов; 3. понимание утвержденных и будущих требований заказчиков в IT-ресурсах, формирование прогнозов относительно требований в будущем; 4. влияние на процесс Управления спросом; 5. формирование Плана обеспечения мощностей; 6. содействие в диагностировании проблем и инцидентов 7. проактивное улучшение услуг и их компонентов там, где это экономически оправдано или требуется бизнесом[10]. Процесс предоставляет поставщику услуг следующую информацию: 1. какие компоненты необходимо обновить (например, больше памяти на запоминающих устройствах или более быстрые процессоры); 2. когда обновлять компоненты; 3. сколько будет стоить обновление компонентов. Многие процессы зависят от Управления мощностями и будут менее эффективны без использования его информации. Например, Управление изменениями должно получить информацию от Управления мощностями перед внесением каких-то изменений, так как они могут повлиять на доступность мощностей. Правильно организованное Управление мощностями дает возможность предсказывать различные события в бизнесе до того, как они фактически случаются. Это помогает избежать неприятных сюрпризов в отношении производительности услуг и их компонентов. Управление мощностями тесно взаимодействует с этапом Построения стратегии и другими процессами планирования. Управление мощностями должно понимать и анализировать краткосрочные, среднесрочные и долгосрочные планы бизнеса и IT, а также следить за трендами, новыми идеями и технологиями, которые можно использовать для осуществления этих планов. Управление мощностями должно обеспечивать следующее: 1. баланс затрат и требуемых ресурсов - обеспечивать то, чтобы производительность процессов была оправдана с точки зрения затрат на них, и обеспечивать наиболее эффективное использование ресурсов. 2. баланс спроса и предложения - следить, чтобы предоставляемые IT предложения удовлетворяли спросу со стороны заказчиков в настоящем и будущем. Управление мощностями является непрерывным процессом, сопровождающим услугу на всем ее жизненном цикле. Он оптимизирует использование имеющихся в наличии ресурсов и планирует их распределение в будущем (рис. 5.3). Рис. 5.3. Процесс Управления мощностями В рамках Управления мощностями выделяют три подпроцесса: 1. Управление мощностями бизнеса - транслирует потребности и планы бизнеса в требования к услугам и инфраструктуре; 2. Управление мощностями услуг - управляет, контролирует и предсказывает производительность и мощность услуг, находящихся в эксплуатации; 3. Управление мощностями компонентов - управляет, контролирует и предсказывает производительность и мощность отдельных компонентов[10]. Конечно, среди этих процессов много общего, но, тем не менее, каждый процесс имеет свой "фокус". Управление мощностями бизнеса сфокусировано на текущих и будущих требованиях бизнеса. Управление мощностями услуг сфокусировано на предоставлении существующих услуг для поддержки бизнеса, Управление мощностями компонентов - на инфраструктуре, которая обеспечивает предоставление услуг. Роль каждого из подпроцессов показана на рис. 5.4. увеличить изображение Рис. 5.4. Подпроцессы в рамках Управления мощностями Выделяют реактивные и проактивные мероприятия в рамках процесса Управления мощностями. К проактивным мероприятиям относятся: 1. "предугадывание" появления вопросов, связанных с нехваткой ресурсов; 2. выделение тенденций использования ресурсов в настоящее время и оценка будущих требований к ресурсам. Последнее выражается в обновлении и улучшении планов в терминах пороговых величин и направлений использования ресурсов; 3. моделирование и анализ тенденций изменений в IT-услугах, в том числе определение изменений в ресурсах, которые должны быть предприняты в будущем; 4. обеспечение того, что обновления будут профинансированы, запланированы и проведены до того, как будет нарушен SLA или появятся какие-то проблемы с производительностью: 5. активный поиск возможностей для улучшения производительности услуг там, где это экономически оправдано; 6. настройка и оптимизация производительности услуг и их компонентов. К реактивным мероприятиям относятся: 1. мониторинг, измерение и ведение отчетности по текущей производительности услуг и их компонентов; 2. реагирование на все события, связанные с пороговыми величинами производительности, и дальнейшая инициализация коррективных мер; 3. реагирование на все проблемы, связанные с производительностью и помощь в их разрешении. Деятельность в рамках процесса Управления мощностями показана на рис. 5.5. увеличить изображение Рис. 5.5. Деятельность в рамках процесса Управления мощностями Чем эффективнее проводятся проактивные мероприятия, тем меньше потребуется реактивных действий со стороны Управления мощностями. Действия в рамках каждого из рассмотренных подпроцессов отличаются. Главным отличием является информация, которая отслеживается и собирается. Например, уровень утилизации отдельных компонентов - процессоров, дисков, сетевого оборудования - вопросы Управления мощностью компонентов. Транзакция между показателями пропускной способности и временем ответа - вопросы Управления мощностью услуг. К вопросам Управления мощностями бизнеса относятся транзакциямежду показателями онлайнуслуг и бизнес-объемов - например, в терминах увеличения продаж или обслуженных ордеров. Входами процесса Управления мощностями являются: 1. информация от бизнеса - стратегии и планы организации, ее текущие и будущие требования; 2. информация от IT - стратегии, планы и бюджет IT. Эта информация покрывает все вопросы, связанные с технологиями, инфраструктурой, окружением, данными и приложениями, и их связи со стратегиями и планами бизнеса; 3. информация о производительности и мощности компонентов; 4. проблемы, связанные с производительностью услуг - инциденты и проблемы, связанные с плохой производительностью; 5. информация о услугах - информация от SLM, в том числе от Каталога услуг и Портфеля услуг, целевые показатели услуг в SLA и SLR и т.п. 6. финансовая информация - информация от процесса Управления финансами, в том числе стоимость предоставления услуг, ресурсов, компонентов и обновлений; выгода для бизнеса, финансовые планы и бюджет; затраты, связанные с отказом услуг или их компонентов. 7. информация об изменениях: от процесса Управления изменениями, в том числе расписание изменений, оценка влияния изменений на мощность. 8. информация о производительности: информация о текущей производительности услуг и их компонентов. 9. информация о текущих связях бизнеса с услугами, вспомогательными услугами и технологиями. 10. информация о рабочей нагрузке. Рабочая нагрузка(Workload) - ресурсы, необходимые для предоставления определенной части услуги. Рабочие нагрузки могут быть категоризированы по пользователям, группам пользователей или функциям в рамках отдельной услуги. Выходами Управления мощностями являются: 1. Система управления мощностями (Capacity Management Information System или CMIS) - виртуальное хранилище для всех данных в рамках Управления мощностями, обычно имеет физически распределенную архитектуру[1]. 2. План обеспечения мощностей; 3. информация и отчеты о производительности услуг: используются различными процессами. Например, для помощи процессу Управления финансами в определении того, сколько денег необходимо выделить на обновления инфраструктуры; 4. анализ рабочей нагрузки и отчеты по ней. Используется персоналом операционного управления для оценки и осуществления изменений. При этом Управление мощностями предоставляет расписание о том, когда используются услуги, и какова рабочая нагрузка, что обеспечивает наиболее эффективное использование ресурсов. 5. отчеты "по случаю" о производительности и мощности (то есть отчеты не по расписанию, а по конкретному случаю). Используются всеми областями Управления мощностями, IT и бизнесом с целью анализа и разрешения проблем. 6. прогнозы, которые используются всеми областями для анализа и прогнозирования, в особенности руководством при принятии решений. Показатели, которые оценивают эффективность Управления мощностями, должны включать: • Точные бизнес-прогнозы: o своевременное формирование прогноза в отношении рабочей нагрузки; o выраженная в процентах точность прогнозов относительно бизнеса; o своевременное объединение бизнес-планов с Планом обеспечения мощностей; o • уменьшение количества расхождений между бизнес-планами и Планом обеспечения мощностей. Знание технологий, в том числе будущих: o улучшение мониторинга производительности и пропускной способности услуг и их компонентов; o своевременное обоснование внедрения и внедрение новых технологий в соответствии с требованиями бизнеса; o уменьшение использования старых технологий, которые вызывают проблемы с поддержкой и производительностью. • Способность демонстрировать экономическую эффективность: o уменьшение случаев "покупки чего-то в последний момент" для решения срочных проблем с производительностью; o уменьшение функционирования услуг и компонентов на грани своих возможностей по производительности и мощности; o точные прогнозы относительно потребления ресурсов; o уменьшение случаев нарушений в бизнес-процессах, вызванных нехваткой мощности со стороны IT; o уменьшение затрат на формирование Плана обеспечения мощностей. • Способность обеспечивать необходимую мощность IT для удовлетворения потребностей бизнеса: 1. процентное уменьшение количества инцидентов, связанных с плохой производительностью. 2. процентное уменьшение потерь для бизнеса связанных с недостаточной мощностью. 3. уменьшение количества "брешей" в SLA, вызванных плохой производительностью услуг и их компонентов[10]. Количество информации, формируемой в рамках трех рассмотренных подпроцессов Управления мощностями, огромно и, как следствие, трудно поддается анализу. Поэтому необходимо сосредотачивать усилия на наиболее важных ресурсах и вопросах их использования. 5.4. Управление доступностью Доступность (Availability) - способность конфигурационной единицы или услуги выполнять согласованную функцию, когда это требуется. Доступность определяется через надежность, сопровождаемость, обслуживаемость, производительность и безопасность. Управление доступностью(Availability Management) - процесс, отвечающий за определение, анализ, планирование, измерение и улучшение всех аспектов доступности услуги. Управление доступностью отвечает за то, чтобы вся инфраструктура, процессы, средства, роли и т.д. соответствовали согласованным Целевым показателям уровня услуги в части Доступности[1]. Главной целью Управления доступностью является гарантия того, что уровень доступности услуг эффективен по затратам и соответствует текущим или будущим потребностям бизнеса. Промежуточными целями процесса являются: 1. формирование Плана управления доступностью. План управления доступностью(Availability Plan) - план, обеспечивающий эффективное по затратам выполнение текущих и будущих требований доступности к услуге[1]; 2. предоставление рекомендации и руководства для других областей бизнеса и IT по всем вопросам, связанным с доступностью; 3. обеспечение того, чтобы услуги достигали установленных целевых показателей в контексте доступности, путем управления услугами и ресурсами; 4. содействие в диагностировании и разрешении проблем, связанных с доступностью; 5. оценка влияния изменений на План управления доступностью; 6. обеспечение того, что проактивные средства для улучшения доступности внедрены там, где это экономически оправдано. Процесс Управления доступностью должен включать в себя следующие деятельности: 1. мониторинг всех аспектов, связанных с доступностью и надежностью услуг и поддерживающих компонентов; 2. управление набором методов, техник и вычислений, необходимых для ведения отчетности и проведения замеров; 3. содействие в оценке рисков и управленческой деятельности; 4. сбор результатов измерений и анализа, формирование регулярных и специальных (для единичных случаев) отчетов о доступности услуг и их компонентов; 5. понимание текущих и будущих потребностей бизнеса в доступности услуг и их компонентов; 6. влияние на проектирование услуг с целью их максимального соответствия потребностям бизнеса; 7. формирование Плана управления доступностью, который позволит поставщику услуг поддерживать и улучшать уровень доступности предоставляемых услуг в соответствии с целевыми показателями, оговоренными в SLA. Он также поможет в планировании и прогнозировании уровней доступности, которые могут потребоваться в будущем. 8. управление расписанием тестов всех компонентов на предмет доступности; 9. содействие в идентификации и разрешении всех проблем и вопросов, связанных с недоступностью услуг и их компонентов. 10. проактивное улучшение доступности услуг там, где это экономически эффективно и соответствует потребностям бизнеса[10]. Удовлетворенность заказчиков во многом зависит от доступности услуг, поэтому процесс Управления доступностью принимает особое значение. Так же, как Управление мощностями, Управление доступностью должно присутствовать на всех этапах жизненного цикла услуги. Управление доступностью включает в себя проактивные и реактивные действия (рис. 5.6). Рис. 5.6. Процесс Управления доступностью Реактивные действия заключаются в мониторинге, измерении, анализе, формировании отчетов и обзоров обо всех аспектах, связанных с доступностью. Они гарантируют то, что целевые показатели доступности достигнуты и измерены. Проактивные действия заключаются в формировании рекомендаций, планов, документов для проектирования и критериев для новых или измененных услуг. Сюда также входят действия по постоянному улучшению услуг и уменьшению рисков там, где это экономически оправдано. Управление доступностью состоит из двух взаимосвязанных уровней: 1. доступность услуг - включает в себя все вопросы, связанные с доступностью и недоступностью услуг, а также влияние доступности (или недоступности) отдельных компонентов на доступность услуг в целом. 2. доступность компонентов - включает в себя все вопросы, связанные с доступностью и недоступностью компонентов. Управление доступностью основано на мониторинге, анализе, измерении и формировании отчетов о следующих компонентах: 1. Доступность - способность услуги, компонента или конфигурационной единицы выполнять согласованную функцию тогда, когда это требуется. Обычно измеряется в процентах по следующей формуле: Доступность(%)=(Согласованное время предоставления услуги-Время простоя)/Согласованное время предоставления услуги*100 Естественно, время простоя включается в расчет при наличии простоя. Если его не было, то доступность услуги будет стопроцентная. 2. Надежность (Reliability) - мера того, как долго услуга, компонент или конфигурационная единица может выполнять согласованную функцию без прерывания. Надежность услуги можно повысить двумя способами. Первый заключается в повышении устойчивости услуги к отказу отдельных компонентов, второй - в увеличении надежности отдельных компонентов. Обычно надежность измеряется с помощью двух показателей: o Среднее время между инцидентами (Mean Time Between Service Incidents или MTBSI) - это среднее время от момента сбоя системы или услуги до следующего сбоя[1]. Надежность(MTBSI в часах)=Время доступности в часах/Количество сбоев o Среднее время между сбоями (Mean Time Between Failures или MTBF)- это среднее время, за которое конфигурационная единица или услуга может выполнять свои функции без перерыва. Измеряется от начала работы до момента следующего сбоя[1]. Надежность(MTBF в часах) = (Время доступности в часах - Общее время простоя в часах)/Количество сбоев 3. Сопровождаемость - мера быстроты и эффективности восстановления нормальной работы конфигурационной единицы или услуги после сбоя. Измеряется с помощью Среднего времени восстановления услуги. Среднее время восстановления услуги(Mean Time to Restore Service или MTRS) - среднее время, требуемое для восстановления конфигурационной единицы или услуги после сбоя. MTRS измеряется от момента сбоя конфигурационной единицы или услуги до момента полного восстановления и возврата к нормальной функциональности[1]. Сопровождаемость (MTRS в часах) = Общее время простоя в часах/Количество сбоев Пример. Пусть услуга, которая используется 7 дней в неделю 24 часа в сутки, проработала 7010 часов. За это время было 2 сбоя. Простой в результате первого сбоя был 10 часов, в результате второго - 5 часов. Доступность=(7010-(5+10))/7010*100=99,78 % Надежность(MTBSI)=7010/2=3505 Надежность(MTBF)=(7010-(5+10))/2=3497.5 часов Сопровождаемость(MTRS)=(5+10)/2=7.5 часов 4. Обслуживаемость - способность поставщика третьей стороны выполнить условия договора. Этот договор будет включать в себя согласованные уровни надежности, сопровождаемости или доступности для конфигурационной единицы[1]. Перечисленные компоненты Доступности и их взаимосвязь показаны на рис. 5.7 увеличить изображение Рис. 5.7. Термины Доступности и их взаимосвязь В контексте процессов Проектирования вводится также термин Критичная бизнесфункция (Vital Business Function или VBF) - функция в бизнес-процессе, критичная для успеха Бизнеса[1]. Чем выше критичность функции для бизнеса, тем большую надежность и доступность в отношении нее необходимо обеспечить. Некоторые VBF требуют особого подхода при проектировании обслуживающих их услуг: o высокая доступность - характеристика услуги, отражающая то, что последствия сбоев компонентов услуги минимизированы и/или незаметны для пользователей. o устойчивость к сбоям - способность услуги, компонента или конфигурационной единицы продолжать работу после сбоя какой-то составляющей. o непрерывная эксплуатация - подход к проектированию, направленный на устранение плановых простоев услуг. Отдельная конфигурационная единица может быть отключена, в то время как услуга останется доступной. o непрерывная доступность - подход к проектированию, направленный на достижение 100% доступности. Непрерывно доступная услуга не имеет планового или внепланового простоя. Входами процесса Управления доступностью являются: 1. информация от бизнеса - стратегия, планы и бюджет организации, ее текущие и будущие требования, в том числе требования к доступности новых или измененных услуг; 2. информация от Анализа влияния на бизнес, в том числе определение перечня VBF; 3. информация от проведенных ранее анализа рисков и оценки; 4. информация об услугах от Портфеля услуг и Каталога услуг; от SLM, в том числе целевые показатели услуг из SLA и SLR; 5. финансовая информация от Управления финансами - стоимость предоставления услуг и затраты на ресурсы; 6. информация о релизах и изменениях от процессов Управления изменениями и Управления релизами, в частности расписания релизов и изменений; 7. информация от Управления конфигурациями о связях бизнеса с услугами, вспомогательными услугами и технологиями. 8. целевые показатели услуг из SLA,SLR, OLA и других контрактов. 9. информация о компонентах - доступность, надежность и сопровождаемость компонентов, которые лежат в основе услуг; 10. информация о технологиях - топология и связи компонентов, а также возможности новых технологий 11. информация о производительности в прошлом; 12. информация о случаях недоступности и сбоях. Выходами процесса Управления доступностью являются: 1. Система управления доступностью (Availability Management Information System или AMIS) - виртуальный репозиторий для всех данных, находящихся под контролем Управления доступности[1]. Обычно это физически распределенное хранилище; 2. План управления доступностью; 3. критерии для проектирования доступности, предлагаемые целевые показатели; 4. отчеты о доступности, надежности и сопровождаемости услуг в контексте достижения ими целевых показателей; 5. отчеты о доступности, надежности и сопровождаемости компонентов в контексте достижения ими целевых показателей; 6. пересмотренный обзор рисков, обновление списка рисков; 7. требования к мониторингу, управлению и отчетности в отношении услуг, которые гарантируют, что любые отклонения в доступности, надежности и сопровождаемости будут обнаружены и устранены; 8. расписание проведения тестирования доступности, надежности и сопровождаемости; 9. расписание для планового и реактивного обслуживания услуг и их компонентов; 10. формирование Ожидаемого простоя услуги. Ожидаемый простой услуги (Projected Service Outage или PSO) - документ, определяющий влияние спланированных изменений, деятельности по обслуживанию и планов тестирования на согласованный Уровень услуг[1]; 11. детальное описание проактивных технологий, которые будут использованы для улучшения надежности и доступности 12. действия по совершенствованию услуг для включения в SIP. Для оценки эффективности процесса Управления доступностью можно использовать множество ключевых показателей производительности, например: • Управление доступностью и надежностью услуг: o процентное уменьшение недоступности услуг и их компонентов o процентное увеличение надежности услуг и их компонентов o эффективный пересмотр SLA, OLA и других основополагающих контрактов и договоров; o процентное улучшение конечной доступности услуг; o процентное уменьшение количества сбоев и их влияния; o улучшение MTBF; o улучшение MTBSI; o улучшение MTRS. • Удовлетворение потребностей бизнеса в доступности услуг: o процентное уменьшение недоступности услуг; o процентное уменьшение стоимости простоя для бизнеса; o процентное уменьшение сбоев во время, критичное для бизнеса; o • процентное увеличение удовлетворенности бизнеса. Оптимальные затраты на обеспечение доступности услуг: o процентное уменьшение стоимости недоступности; o своевременное завершение Анализа рисков и обзора системы; o своевременно завершение анализа рисков "затраты-выгоды"; o процентное уменьшение сбоев компонентов и услуг третьих сторон; o сокращение времени на проведение Анализа рисков; o сокращение времени на проведение анализа системы на надежность; o сокращение времени на формирование Плана управления доступностью; o своевременное формирование управленческих отчетов. Управление доступностью должно формировать и управлять AMIS. AMIS является центральным репозитарием для хранения всей информации, документов, метрик и т.п., необходимых для осуществления Управления доступностью. Рекомендуется формировать План управления доступностью на срок один-два года, с детализацией на первые полгода. План должен регулярно пересматриваться и обновляться. Основным риском для процесса Управления доступностью, также как и для предыдущих процессов, является недостаточность или неточность информации, поступающей от бизнеса и IT. Лекция 6: Управление непрерывностью услуг и информационной безопасностью в рамках этапа Проектирования. Управление поставщиками Аннотация: Процессы и деятельности в рамках этапа Проектирования услуг: Управление непрерывностью услуг и информационной безопасностью в рамках этапа Проектирования. Управление поставщиками. Для каждого процесса рассматривается цель, входы и выходы, основные деятельности и ключевые показатели эффективности. Ключевые слова: управление рисками, процесс управления, бизнеспроцесс, BCM, деятельность, ITIL, значимость, анализ, активы, бизнес-процессы, связь, жизненный цикл, цикла, запуск, устойчивость, затраты, информация, механизмы, BIA, безопасность персонала, базис, уязвимость, management, очередь, обнаружение нарушений, опция, ITSCM, SLA, требования безопасности, интервал, эксплуатация, SLM, SLR, конфиденциальность, целостность, управление информационной безопасностью, доступ, ISM, информационная безопасность, место, контроль безопасности, политика использования, безопасность, идентификация активов, угроза, ущерб, ITSM, supplier, provider, слово, интегрирование, провайдер, объединение, к атегоризация, база данных, категорирование, общий риск, операционные требования, обмен информацией 6.1. Управление непрерывностью услуг Управление непрерывностью услуг (IT Service Continuity Management или ITSCM) процесс, ответственный за управление рисками, которые влияют на услуги. ITSCM обеспечивает возможность поставщику услуг постоянно предоставлять минимально согласованный Уровень услуг, через снижение рисков до приемлемого уровня и Планирование восстановления услуг[1]. Основная цель Управления непрерывностью услуг (далее просто Управление непрерывностью) поддерживать процесс Управления непрерывностью бизнеса. Управление непрерывностью бизнеса (Business Continuity Management или BCM) - бизнес-процесс, отвечающий за управление рисками, которые могут серьезно повлиять на бизнес. BCM защищает интересы ключевых заинтересованных сторон, репутацию, бренд и деятельность по созданию ценности. Процесс BCM включает в себя снижение рисков до приемлемого уровня и планирование способов восстановления бизнес-процессов в случае нарушения бизнеса. BCM устанавливает цели, охват и требования по отношению к Управлению непрерывности ИТ-услуг[1]. В настоящее время технологии являются основным компонентом многих бизнес процессов, поэтому обеспечение их непрерывности и доступности является необходимым для существования бизнеса в целом. ITSCM управляет способностью услуг и их компонентов к восстановлению. Промежуточные цели ITSCM: 1. управление набором Планов обеспечения непрерывности услуг и Планов восстановления услуг, которые являются частью Планов обеспечения непрерывности бизнеса. План обеспечения непрерывности услуг (IT Service Continuity Plan) - план, определяющий шаги, необходимые для восстановления одной или нескольких услуг. План также должен определять события, которые являются основанием для его инициации, людей, которые должны быть задействованы, средства коммуникаций и т.п. План обеспечения непрерывности бизнеса (Business Continuity Plan или BCP) - план определяет шаги, необходимые для восстановления бизнес-процессов в случае нарушения их функционирования. План также должен содержать информацию о событиях, которые являются основанием для его инициирования; людях, которые должны быть задействованы в реализации плана; средствах коммуникаций и т.п.[1] 2. завершение Анализа влияния на бизнес в части гарантии управления планами обеспечения непрерывности в соответствии с изменяющимися требованиями и потребностями бизнеса; 3. сопровождение Анализа рисков и менеджмента, в частности при взаимодействии с бизнесом и процессами Управления доступностью и Управления безопасностью, которые управляют услугами в соответствии с согласованным Уровнем услуг; 4. предоставление рекомендаций и руководств другим областям IT в вопросах, связанных с непрерывностью и восстановлением услуг; 5. обеспечение механизмов непрерывности и восстановления, которые позволят достигнуть целевых показателей, установленных бизнесом; 6. оценка влияния изменений на Планы обеспечения непрерывности услуг и Планы восстановления услуг; 7. проактивное улучшение непрерывности услуг там, где это экономически эффективно; 8. ведение переговоров и заключение контрактов с поставщиками об обеспечении необходимой способности к восстановлению в целях поддержки непрерывности (с участием процесса Управления поставщиками)[10]. Управление непрерывностью фокусируется на значимых негативных событиях, которые ITIL называет "катастрофами" для бизнеса. Менее значимые события рассматриваются в рамках процесса Управления инцидентами. То, является ли какое-то конкретное событие катастрофой, зависит от организации, в которой оно произошло. Размер и значимость негативного влияния события на бизнес, например, финансовые потери или потеря репутации, измеряется в рамках Анализа влияния на бизнес. Анализ влияния на бизнес определяет минимальные требования к критичности, конкретные требования к технологиям и услугам определяются в рамках Управления непрерывностью. ITSCM главным образом рассматривает активы IT и конфигурации, которые поддерживают бизнеспроцессы. В случае катастрофы бизнесу необходимо перестроиться на альтернативную рабочую локацию. При этом необходимо предоставить такие элементы как удобство офиса для персонала, копии критических бумажных отчетов, услуги курьеров и телефонную связь для связи с клиентами и партнерами. В этой связи Управление непрерывностью должно учитывать количество и месторасположение офисов организации, а также услуги, предоставляемые в каждом из них. В рамках Управления непрерывностью должны выполняться следующие деятельности: 1. Согласование границ ITSCM и применяемых политик; 2. Анализ влияния на бизнес для количественной оценки влияния потери услуги на бизнес; 3. Анализ рисков - идентификация и оценка рисков с целью определения потенциальных угроз непрерывности и оценки вероятности их осуществления. Сюда также входит применение механизмов управления угрозами там, где это экономически эффективно; 4. формирование стратегии ITSCM, интегрированной в стратегию BCM. 5. формирование Планов обеспечения непрерывности, интегрированных в планы BCM. 6. Тестирование планов обеспечения непрерывности; 7. Непрерывное осуществление планов и управление ими. На рис. 6.1 показан жизненный цикл ITSCM. Рис. 6.1. Жизненный цикл ITSCM ITSCM циклически повторяется на всем жизненном цикле услуги и гарантирует то, что однажды разработанные планы по восстановлению и обеспечению непрерывности услуг будут соответствовать в дальнейшем приоритетам бизнеса и Планам обеспечения непрерывности бизнеса. На рис. 6.1 также показана роль BCM в ITSCM. Стадии инициализации и формирования требований относятся к BCM. ITSCM должен только участвовать в этих стадиях, чтобы поддержать BCM и понять связи между бизнес-процессами и влияние потери услуг на них. В результате этих начальных стадий BCM формирует Стратегию обеспечения непрерывности бизнеса. Для ITSCM первой серьезной задачей становится сформировать свою стратегию, которая сделает возможной и поддержит Стратегию непрерывности бизнеса. Рассмотрим стадии жизненного цикла ITSCM. Стадия 1 - Запуск Эта стадия ITSCM состоит из следующих действий: • формирование политики обеспечения непрерывности - должно быть осуществлено как можно быстрее. Политика, как минимум, должна определять цели и моменты и вопросы, на которые менеджмент должен обратить внимание; • определение терминов охвата и компетенции - определение границ ITSCM и распределение ответственности для всего персонала в организации; • распределение ресурсов - формирование окружения для обеспечения непрерывности бизнеса, требующего значительных ресурсов как денежных, так и людских. • определение проекта для организации процесса ITSCM и структуры его контроля - ITSCM и BCM являются сложными процессами, требующими тщательной организации и контроля. • согласование проекта и планов качества - планы обеспечивают контроль проекта и его применимость для различных ситуаций. Стадия 2 - Требования и стратегия Установление требований бизнеса к непрерывности услуг является критически важным, так как именно от этого этапа зависит устойчивость организации к катастрофам и соответствующие затраты. Если требования некорректны или пропущена какая-то важная информация, все механизмы ITSCM будут неэффективны. Эта стадия разделяется на две подстадии: • требования - Анализ влияния на бизнес и оценка рисков • стратегия - стратегия формулирует меры уменьшения риска и опции восстановления. Анализ влияния на бизнес (Business Impact Analysis или BIA) - деятельность в рамках процесса Управления непрерывностью бизнеса, которая определяет критичные бизнес-функции и их зависимость от факторов окружения. Этими факторами могут быть поставщики, люди, другие бизнес-процессы, услуги и т.д[1]. BIA определяет последствия потери услуг для бизнеса. Потери могут быть значительными, например, крупные финансовые потери, и "мягкими" моральные потери, потеря репутации, конкурентного преимущества и т.п. Анализ влияния на бизнес определяет: • форму, которую может приобретать разрушение или потеря, например: o потерянный доход; o дополнительные затраты; o вред репутации; o потеря благосклонности клиентов; o потеря конкурентного преимущества; o повреждение и нарушение здоровья, законности и безопасности; o риск безопасности персонала; o потеря рынка сбыта в краткосрочном и долгосрочном периодах; o потеря операционных возможностей, например, контроля. • как будут увеличиваться негативные последствия разрушения или потери после неблагоприятного события, а также время суток, недели, месяца, когда они будут наиболее серьезными; • кадровое обеспечение, навыки, аппаратура и услуги, которые необходимы для поддержки минимальных уровней непрерывности критичных бизнес-процессов; • временные рамки, в пределах которых необходимо обеспечить минимальный уровень восстановления кадрового обеспечения, аппаратуры, услуг и других возможностей; • временные рамки, в пределах которых необходимо полностью восстановить критичные бизнеспроцессы и поддерживающие их кадровое обеспечение, аппаратуру, услуги и другие возможности; • приоритеты восстановления для услуг. Одним из основных выходов BIA является построение диаграммы оценки влияния потери услуги или бизнес-процесса на бизнес в целом (рис. 6.2). увеличить изображение Рис. 6.2. Графическое представление влияния на бизнес Анализ влияния на бизнес предоставляет базис для осуществления ITSCM. На основе анализа формируется перечень услуг, приложений и других компонентов, которые станут предметами рассмотрения ITSCM. Второй этап определения требований для ITSCM заключается в оценке вероятности возникновения неприятных событий. Оценка рисков (Risk Assessment) - начальные шаги Управления рисками. Анализируется ценность активов для бизнеса, идентифицируются угрозы по отношению к этим активам, и оценивается уязвимость активов по отношению к этим угрозам[1]. Для оценки рисков и управления ими применяется стандартная методология M_o_R (Management of Risks), которая состоит из следующего: • принципы M_o_R - базируются на принципах управления организацией и являются необходимыми для эффективного управления рисками; • подход M_o_R - подход организации к указанным выше принципам должен быть отображен в ряде документов, в частности, в Политике управления рисками. • процессы M_o_R. Выделяют четыре процесса в рамках M_o_R: o Определение - определение угроз для деятельности, которые могут повлиять на достижение ею намеченного результата; o Оценка - оценка суммарного влияния всех определенных угроз; o Планирование - определение набора управленческих действий, которые уменьшат риски; o Реализация - осуществление запланированных управленческих действий, их контроль, определение эффективности и корректирование в случае необходимости. • пересмотр и внедрение M_o_R - внедрение процессов, политик и подхода M_o_R так, чтобы они непрерывно контролировались и оставались эффективными; • взаимодействие - обеспечение взаимодействия всех действий в рамках M_o_R с целью поддержки актуальности информации об угрозах, возможностях и других аспектах Управления рисками. Действия в рамках ITSCM должны быть направлены на уменьшение влияния рисков и вероятности их возникновения. Результаты Анализа влияния на бизнес и Оценки рисков являются основой для построения Стратегии непрерывности услуг в соответствии с потребностями бизнеса. Большинство организаций должны соблюдать баланс уменьшения рисков и формирования механизмов восстановления. Как бы хорошо ни проводились действия по уменьшению рисков, невозможно исключить их все. Поэтому всегда необходимо внедрять механизмы восстановления в интеграции с процессом Управления доступностью, так как именно доступность услуг пострадает в первую очередь при возникновении неприятных для бизнеса событий. Типичные меры уменьшения рисков включают в себя: • инсталляция UPS и резервного питания для компьютеров; • обеспечение отказоустойчивости систем с критичными приложениями, для которых неприемлем любой простой (например, банковская система); • использование RAID и зеркальных дисков для серверов для избегания потери информации и обеспечения непрерывности работы; • наличие запасных компонентов/оборудования, которые будут использованы в случае сбоя основных. Например, запасной сервер с минимально необходимой конфигурацией, который будет задействован в кратчайшее время в случае отказа основного сервера; • устранение SPOFов, например, единой точки доступа в сеть или единой точки электропитания. • использование надежных IT-систем и сетей; • аутсорсинг услуг нескольким поставщикам услуг; • увеличение контроля над безопасностью; • увеличение контроля над обнаружением нарушений в работе услуг; • всеобъемлющая стратегия восстановления и резервного копирования, включающая в себя внешнее хранение. Внешнее хранение предполагает регулярное (чаще всего ежедневное) копирование критичной информации во внешнее хранилище. Перечисленные выше меры не решат всех вопросов ITSCM, но их использование позволит сильно сократить риск потерь для бизнеса в случае возникновения непредвиденных обстоятельств. Опции восстановления в рамках ITSCM, которые должны быть учтены при формировании стратегии: • переход на ручную работу для некоторых типов услуг может стать хорошей альтернативой на короткий период до восстановления услуги. Например, Сервис-деск может работать какое-то время с бумажными заявками и журналами; • взаимные соглашения являются еще одной опцией для восстановления. Предполагают заключение соглашений между организациями, использующими похожие технологии. В настоящее время являются неприемлемыми для большинства IT-систем, но могут использоваться в отдельных случаях - например, для внешнего резервного копирования или использования принтеров; • постепенное восстановление (Gradual Recovery) - способ восстановления, также известный как "холодное резервирование". Предусматривается восстановление услуги в течение более чем 72 часов. При постепенном восстановлении обычно задействован мобильный или стационарный резервный центр, оснащенный элементами жизнеобеспечения и сетевой разводкой, без компьютерных систем[1]. Эта опция восстановления рекомендована для некритичных услуг, предоставление которых может быть задержано на дни и недели без значительного влияния на бизнес; • промежуточное восстановление (Intermediate Recovery) - способ восстановления, также известный как "теплое резервирование". Предусматривается восстановление услуги в течение 24 - 72 часов. При промежуточном восстановлении обычно используется общий мобильный или стационарный резервный центр, оснащенный компьютерными системами и сетевыми компонентами. Конфигурирование аппаратного и программного обеспечения, а также восстановление данных выполняются в рамках Плана обеспечения непрерывности услуг[1]. Данная опция восстановления обычно предлагается третьими сторонами, которые имеют для этого все необходимое оборудование и квалифицированный персонал. Стоимость этой опции восстановления зависит от ресурсов третьей стороны, которые должны быть задействованы для восстановления, а также от времени, в течение которого требуется восстановить услугу. Преимуществом данного метода является его прозрачность для пользователей. Недостатком - то, что информация (в том числе конфиденциальная) будет храниться у сторонней организации. Последнее делает неприемлемым данный способ восстановления для многих организаций. • быстрое восстановление (Fast Recovery) - способ восстановления. Предусматривается восстановление услуги за короткий промежуток времени, обычно менее 24 часов. При быстром восстановлении обычно используется выделенный стационарный резервный центр с компьютерными системами и ПО, сконфигурированными для работы услуг. Немедленное восстановление может занимать до 24 часов, если требуется восстановление данных резервного копирования[1]. • немедленное восстановление (Immediate recovery) - способ восстановления, также известный как "горячее резервирование". Предусматривается восстановление услуги без прерывания услуги. Немедленное восстановление обычно использует технологии зеркалирования, балансировки загрузки и разделения площадок установки оборудования[1]. Этот способ чаще всего предусматривает "двойную локацию" компонентов системы, то есть полное дублирование. Он является самым дорогим и применяется только для критичных бизнеспроцессов, простой которых может оказать значительное негативное влияние на бизнес. Копии должны быть расположены на максимальном удалении от оригиналов, чтобы не быть задетыми разрушающим событием. Стратегия обеспечения непрерывности должна включать в себя все рассмотренные выше способы восстановления. Различные услуги, используемые организацией, требуют различных подходов к восстановлению и уменьшению рисков сбоя. Какая бы опцияни выбиралась, она должна быть экономически эффективной. Главное правило - чем дольше бизнес может обходиться без услуги, тем дешевле должно быть решение по обеспечению ее непрерывности. Стадия 3 - Реализация После того, как Стратегия обеспечения непрерывности определена, необходимо разработать Планы обеспечения непрерывности услуг в соответствии с Планами обеспечения непрерывности бизнеса. Планы ITSCM должны рассматривать все действия, которые необходимо предпринять для предоставления требуемых услуг, возможностей и ресурсов с соответствующими уровнями непрерывности. Это значит не только рассмотрение вопросов, связанных с восстановлением услуг и возможностей, но и понимание зависимостей между ними, тестирование, проверка целостности и последовательности данных. Планы ITSCM также должны включать документацию о средствах обеспечения надежности и мерах восстановления, обоснование применения конкретных мер в зависимости от ситуации. При формировании планов необходимо убедиться в том, что в них детально рассмотрены и документированы все действия по восстановлению в случае сбоя. Планы ITSCM должны включать в себя такие основные моменты как точка восстановления данных, перечень зависимых систем, природа этой зависимости, требования к программному и аппаратному обеспечению, конфигурационные детали и другую важную информацию о системах и услугах. Одним из наиболее важных источников информации для формирования планов является Анализ влияния на бизнес. Другие области также должны быть проанализированы: SLA, требования безопасности, инструкции эксплуатации, процедуры, внешние контракты. Помимо разработки Планов обеспечения непрерывности для того, чтобы следовать принятой Стратегии обеспечения непрерывности, необходимы следующие действия: 1. Планирование организационной структуры В случае возникновения катастрофы, организационная структура вероятнее всего претерпит изменения и будет основана, прежде всего, на следующем: o руководство - топ-менеджеры и правление организации, которые обладают властью и средствами контроля над организацией. Именно руководство ответственно за управление в кризисной ситуации; o координация - уровень, ответственный за координацию внутри процесса восстановления; o восстановление - совокупность групп бизнеса и IT, которые представляют критичные бизнес-функции и услуги, поддерживающие эти функции. Каждая группа ответственна за исполнение планов восстановления своей области при взаимодействии с персоналом, пользователями и третьими сторонами[10]. 2. Тестирование Планы по восстановлению должны пройти тестирование. Тестирование является важной частью ITSCM. Именно оно гарантирует то, что принятые стратегия, соглашения, планы и процедуры будут действительно работать на практике. Поставщик услуг ответственен за то, что в случае катастрофы услуги могут быть восстановлены в заданный временной интервал с требуемой функциональностью и производительностью. Тесты должны проводиться по максимально реалистичным сценариям. Тем не менее, необходимо понимать, что даже самое тщательное тестирование не может учесть все нюансы, которые могут возникнуть в реальности. Стадия 4 - Непрерывная эксплуатация Эта стадия состоит из следующего: 1. Обучение, готовность, тренинги - персонал должен быть готов к возникновению непредвиденных обстоятельств и знать, что необходимо делать при их возникновении; 2. Пересмотр - все выходы процесса ITSCM должны регулярно пересматриваться на предмет актуальности и корректироваться в случае необходимости; 3. Тестирование - помимо начального тестирования, необходимо предусмотреть регулярное тестирование стратегии, планов и других выходов ITSCM. Резервные копии и механизмы восстановления также должны тестироваться; 4. Управление изменениями - процесс, ответственный за оценку изменений с точки зрения их влияния на планы ITSCM. Инициирование является заключительным тестом для Планов обеспечения непрерывности бизнеса и услуг. Этот процесс должен рассматривать процедуру запуска планов по восстановлению в случае непредвиденных обстоятельств. Необходимо помнить, что решение об инициации планов должно быть хорошо взвешенным, особенно в случае использования услуг восстановления третьих сторон. Сбой может произойти в любое время дня и ночи, поэтому важно иметь возможность незамедлительно инициировать планы по восстановлению. Входами ITSCM являются: 1. информация от бизнеса - стратегия, планы и бюджет организации, текущие и будущие требования; 2. информация от IT - стратегия, планы и бюджет IT; 3. стратегия и планы обеспечения непрерывности бизнеса; 4. информация об услугах - информация от SLM, в частности из Портфеля услуг и Каталога услуг, SLA/SLR; 5. финансовая информация - информация от процесса Управления финансами о стоимости предоставления услуг, ресурсов и компонентов; 6. информация об изменениях - информация от процесса Управления изменениями, в частности расписание изменений и их влияние на Планы обеспечения непрерывности; 7. информация о взаимоотношениях бизнеса с услугами, вспомогательными услугами и технологиями. 8. расписания Управления непрерывностью бизнеса и Управления доступностью; 9. Планы обеспечения непрерывности услуг и отчеты тестирования партнеров, поставщиков. Выходами ITSCM являются: 1. политика и стратегия ITSCM; 2. набор планов, в том числе планы Антикризисного управления, Срочных ответных действий, Восстановления после катастрофы, а также совокупность вспомогательных планов и контрактов с поставщиками услуг по восстановлению. Антикризисное управление (Crisis Management) - процесс, отвечающий за управление непрерывностью бизнеса в самом широком смысле. Команда антикризисного управления отвечает за стратегические вопросы, такие как управление взаимодействием со средствами массовой информации и доверием акционеров, а также принимает решение об инициации планов обеспечения непрерывности бизнеса[1]. 3. Анализ влияния на бизнес и соответствующие отчеты; 4. Анализ рисков и управленческие обзоры и отчеты; 5. расписание тестирования ITSCM; 6. сценарии для проведения тестирования; 7. обзоры и отчеты по тестированию ITSCM[10]. Ключевым показателем производительности ITSCM является то, что предоставляемые услуги могут быть восстановлены с целью поддержки бизнеса в достижении поставленных целей: 1. проводится регулярный аудит планов ITSCM с целью проверки того, что требования бизнеса к восстановлению могут быть удовлетворены; 2. все целевые показатели восстановления услуг документированы, согласованы в SLA и могут быть достигнуты с помощью планов ITSCM; 3. проводится регулярное и всеобъемлющее тестирование планов ITSCM; 4. заключены все необходимые для ITSCM контракты с третьими сторонами; 5. обеспечивается уменьшение рисков и негативного влияния сбоев услуг. В качестве показателя эффективности может также выступать готовность организации к действиям в соответствии с планами ITSCM. Основными рисками для ITSCM являются недостаточность и некорректность информации, поступающей от бизнеса, IT и других процессов, а также нехватка ресурсов для обеспечения непрерывности. 6.2. Управление информационной безопасностью Управление информационной безопасностью (Information Security Management или ISM) - процесс, который обеспечивает конфиденциальность, целостность и доступность активов, информации, данных и услуг организации. Управление информационной безопасностью обычно является частью Организационного подхода к Управлению безопасностью, который имеет более широкую область охвата, чем поставщик услуг, и включает обработку бумажных документов, доступ в здания, телефонные звонки и т.п., для всей организации[1]. Основной целью ISM является обеспечение эффективного управления информационной безопасностью всех услуг и деятельностей в рамках Управления услуг. Информационная безопасность предназначена для защиты от нарушения конфиденциальности, доступности и целостности информации, информационных систем и коммуникаций. 1. Конфиденциальность - состояние информации, при котором доступ к ней осуществляют только субъекты, имеющие на него право. 2. Целостность - состояние информации, при котором отсутствует любое ее изменение либо изменение осуществляется только преднамеренно субъектами, имеющими на него право; 3. Доступность - состояние информации, при котором субъекты, имеющие право доступа, могут реализовывать его беспрепятственно[15]. Цель обеспечения информационной безопасности достигнута, если: 1. Информация доступна тогда, когда это требуется, а информационные системы устойчивы к атакам, могут избегать их или быстро восстанавливаться. 2. Информация доступна только тем, кто имеет соответствующие права. 3. Информация корректна, полна и защищена от неавторизованных изменений. 4. Обмен информацией с партнерами и другими организациями надежно защищен. Бизнес определяет, что и как должно быть защищено. При этом для эффективности и целостности обеспечения информационной безопасности необходимо рассматривать бизнес процессы от начала до конца, так как слабое место может сделать уязвимой всю систему. Процесс ISM должен включать в себя: • формирование, управление, распространение и соблюдение Политики информационной безопасности и других вспомогательных политик, которые имеют отношение к информационной безопасности. Политика информационной безопасности (Security Policy) - политика, определяющая подход организации к управлению информационной безопасностью [1]. • понимание согласованных текущих и будущих требований бизнеса к безопасности; • использование контролей безопасности для выполнения Политики информационной безопасности и управления рисками, связанными с доступом к информации, системам и услугам. Термин "контроль безопасности" является заимствованным из английского языка и в данном контексте означает набор контрмер и мер предосторожности, применяемых для аннулирования, уменьшения рисков и противостояния им. То есть контроль безопасности состоит из проактивных и реактивных действий; • документирование перечня контролей безопасности, действий по их эксплуатации и управлению, а также всех связанных с ними рисков; • управление поставщиками и контрактами, требующими доступа к системам и услугам. Осуществляется при взаимодействии с процессом Управления поставщиками; • контроль всех "брешей" безопасности и инцидентов, связанных с системами и услугами; • проактивное улучшение контролей безопасности и уменьшение рисков нарушения информационной безопасности; • интеграция аспектов информационной безопасности во все процессы Управления услуг. Политика информационной безопасности должна включать в себя следующее: • реализация аспектов Политики информационной безопасности; • возможные злоупотребления аспектами Политики информационной безопасности; • политика контроля доступа; • политика использования паролей; • политика электронной почты; • политика интернета; • политика антивирусной защиты; • политика классификации информации; • политика классификации документов; • политика удаленного доступа; • политика доступа поставщиков к услугам, информации и компонентам; • политика размещения активов. Перечисленные политики должны быть доступны пользователям и заказчикам, которые в свою очередь обязаны письменно подтвердить свое согласие с ними. Политики утверждаются руководством бизнеса и IT и пересматриваются в зависимости от обстоятельств. Чтобы обеспечивать информационную безопасность и управлять ею, необходимо поддерживать Систему управления информационной безопасностью. Система управления информационной безопасностью (Information Security Management System или ISMS) - система политик, процессов, стандартов, руководящих документов и средств, которые обеспечивают организации достижение целей управления информационной безопасностью[1]. На рис. 6.3 показана структура ISMS, наиболее широко используемая организациями. Рис. 6.3. ISMS На рис. 6.3 представлены 5 элементов структуры ISMS: 1. Контроль. Цели контроля: o формирование системы управления информационной безопасностью в рамках организации; o формирование организационной структуры для подготовки, утверждения и реализации Политики информационной безопасности; o распределение ответственностей; o формирование документации по контролю. 2. Планирование. Цель планирования - разработать и рекомендовать подходящие метрики и способы измерения информационной безопасности. В первую очередь планирование должно учитывать требования и особенности конкретной организации. Источниками информации для формирования требований к информационной безопасности являются бизнес, риски, планы, стратегия, соглашения ( в первую очередь OLA и SLA). При этом важно учитывать моральную, законодательную и этическую ответственности в контексте информационной безопасности. 3. Реализация. Цель реализации - обеспечение подходящих процедур, инструментов и контролей безопасности для поддержки Политики информационной безопасности. В рамках реализации проводятся следующие мероприятия: o идентификация активов - совместно с Управлением конфигурациями; o классификация информации - информация и информационные хранилища должны быть классифицированы в соответствии с их чувствительностью и значимостью по отношению к трем аспектам информационной безопасности (конфиденциальности, целостности, доступности). 4. Оценка. Цель оценки в рамках ISMS: o проверка соответствия политики информационной безопасности требованиям к информационной безопасности из SLA и OLA; o проведение регулярных проверок технической составляющей информационной безопасности для IT систем; o предоставление информации для регуляторов и внешних аудиторов при необходимости; 5. Поддержка. Цели поддержки ISMS: o улучшение соглашений в отношении информационной безопасности, например, SLA и OLA o совершенствование средств и контролей информационной безопасности[10]. Ключевые деятельности в рамках ISM: 1. формирование, пересмотр и корректирование Политики информационной безопасности и набора поддерживающих ее вспомогательных политик; 2. реализация и соблюдение политик информационной безопасности, а также обеспечение взаимодействия между ними; 3. оценка и классификация всех информационных активов и документов; 4. использование, пересмотр и корректирование набора контролей безопасности, мер по оценке рисков и ответных действий; 5. мониторинг и управление "брешами" безопасности и инцидентами; 6. анализ, ведение отчетности и уменьшение влияния "брешей" в безопасности и инцидентов; 7. составление расписания и проведение аудитов, тестирования и обзоров. Взаимодействие указанных деятельностей представлено на рис. 6.4. увеличить изображение Рис. 6.4. Ключевые деятельности в рамках ISM Для обеспечения и поддержки Политики информационной безопасности необходимо сформировать и использовать набор контролей безопасности. Для предотвращения инцидентов и правильного реагирования в случае их возникновения используют меры безопасности, представленные на рис. 6.5. Рис. 6.5. Контроли безопасности На рис. 6.5 выделено четыре стадии. Первая стадия - возникновение угрозы. Угрозой является все, что может негативно повлиять на бизнес-процесс или прерывать его. Инцидент - это реализованная угроза. Инцидент является отправной точкой для применения контролей безопасности. В результате инцидента появляется ущерб. Для управления или устранения рисков также применяются контроли безопасности. Для каждой стадии необходимо подобрать подходящие меры обеспечения информационной безопасности: 1. превентивные - меры безопасности, которые предотвращают появление инцидента информационной безопасности. Например, распределение прав доступа. 2. восстановительные - меры безопасности, направленные на уменьшение потенциального ущерба в случае инцидента. Например, резервное копирование. 3. обнаруживающие - меры безопасности, направленные на обнаружение инцидентов. Например, антивирусная защита или система обнаружения вторжений. 4. подавляющие - меры безопасности, которые противодействуют попыткам реализации угрозы, то есть инцидентам. Например, банкомат забирает у клиента карту после определенного количества неправильных вводов PIN-кода. 5. корректирующие - меры безопасности, направленные на восстановления после инцидента. Например, восстановление резервных копий, откат на предыдущее рабочее состояние и т.п. Входами процесса ISM являются: 1. информация от бизнеса - стратегии, планы, бюджет бизнеса, а также его текущие и будущие требования; 2. политики безопасности бизнеса, планы безопасности, Анализ рисков; 3. информация от IT - стратегия, планы и бюджет IT; 4. информация об услугах - информация от SLM, в частности Портфеля услуг и Каталога услуг, SLA/SLR; 5. отчеты процессов и анализа рисков от ISM, Управления доступностью и Управления непрерывностью услуг; 6. детальная информация обо всех инцидентах информационной безопасности и "брешах" в ней; 7. информация об изменениях - информация от процесса Управления изменениями, в частности расписание изменений и их влияние на планы, политики и контроли информационной безопасности; 8. информация о взаимоотношениях бизнеса с услугами, вспомогательными услугами и технологиями; 9. информация о доступе партнеров и поставщиков к услугам и системам, предоставляемая процессами Управления поставщиками и Управления доступностью. Выходами ISM являются: 1. всеобъемлющая Политика информационной безопасности и другие вспомогательные политики, которые имеют отношение к информационной безопасности;. 2. Система управления информационной безопасностью (ISMS), которая содержит всю информацию, необходимую для обеспечения ISM; 3. результаты переоценки рисков и ревизии отчетов; 4. набор контролей безопасности, описание их эксплуатации и управления, а также всех связанных с ними рисков; 5. аудиты информационной безопасности и отчеты; 6. расписание тестирования планов информационной безопасности; 7. классификация информационных активов; 8. отчеты о существующих "брешах" в информационной безопасности и инцидентах; 9. политики, процессы и процедуры для управления доступом поставщиков и партнеров к услугам и системам. В качестве ключевых показателей производительности процесса Управления информационной безопасностью можно использовать множество метрик, например: 1. защищенность бизнеса от нарушений информационной безопасности o процентное уменьшение сообщений о "брешах" в Сервис-деск; o процентное уменьшение негативного влияния на бизнес со стороны "брешей" и инцидентов; o процентное увеличение пунктов, касающихся информационной безопасности, в SLA. 2. формирование четкой и согласованной политики информационной безопасности, учитывающей потребности бизнеса, то есть уменьшение количества несовпадений между процессами ISM и процессами и политиками информационной безопасности бизнеса. 3. процедуры по обеспечению безопасности, которые оправданы, согласованы и утверждены руководством организации: o увеличение согласованности и пригодности процедур обеспечения безопасности; o увеличение поддержки со стороны руководства 4. механизмы улучшения: o количество предложенных улучшений в отношении контролей и процедур; o уменьшение количества несовпадений, обнаруженных в процессе тестирования и аудита. 5. информационная безопасность является неотъемлемой частью услуг и процессов ITSM, то есть увеличение количества услуг и процессов, в которых предусмотрены меры безопасности[10]. ISM сталкивается со множеством трудностей и рисков на пути обеспечения информационной безопасности. К сожалению, на практике достаточно часто бизнес считает, что вопросами информационной безопасности должна заниматься только IT. Еще хуже, когда бизнес не понимает, зачем вообще нужно уделять внимание информационной безопасности. Создание эффективной системы защиты информации влечет за собой большие затраты, которые должны быть понятны руководству, так как именно оно принимает решение о финансировании. При этом важно соблюдать баланс - обеспечение информационной безопасности не должно стоить больше самой защищаемой информации. 6.3. Управление поставщиками Управление поставщиками (Supplier Management) - процесс, ответственный за обеспечение того, что договоры с поставщиками соответствуют требованиям бизнеса, и все поставщики выполняют свои контрактные обязательства[1]. Прежде чем говорить о данном процессе далее, необходимо разобраться в терминах. Здесь может возникнуть путаница. В английском языке используется два отдельных слова - "supplier", что означает "поставщик", и "provider", что означает поставщик услуг. Таким образом, на русском слово одно - "поставщик". В контексте Управления поставщиками рассматривается управление "supplier(ами)". Поставщик (Supplier) - третья сторона, ответственная за поставку товаров или услуг, необходимых для предоставления ИТ-услуг. Примеры поставщиков: вендоры программного и аппаратного обеспечения, сетевые телекоммуникационные провайдеры, а также аутсорсинговые организации[1]. Из определения ясно, что поставщик может также предоставлять IT-услуги, но ключевым является то, что это третья сторона. То есть ранее мы говорили о взаимодействии двух сторон - поставщика услуг и заказчика, "supplier" же является третьей стороной. В этом топике "provider" будет поставщиком услуг, а "supplier" просто поставщиком. Очень важным является интегрирование процесса Управления поставщиками во все стадии жизненного цикла услуг, так как поставщики играют огромную роль в предоставлении услуг. Промежуточные цели процесса Управления поставщиками: 1. получение ценности за потраченные бизнесом деньги; 2. обеспечение того, что все основополагающие контракты и соглашения с поставщиками соответствуют требованиям бизнеса, требованиям SLA и SLR; 3. управление взаимоотношениями с поставщиками; 4. управление производительностью поставщиков; 5. ведение переговоров и заключение контрактов с поставщиками, а также управление ими внутри жизненного цикла услуг; 6. управление политикой поставщиков и поддерживающей Базой поставщиков и договоров. Каждый провайдер должен иметь структурированный подход к управлению поставщиками для эффективного предоставления своих услуг. Многие поставщики поставляют вспомогательные услуги и продукты, которые сами по себе имеют маленькое влияние на предоставление услуг. Однако объединение вспомогательных услуг и продуктов поставщиков вносит большой вклад в итоговую ценность услуг, предоставляемых заказчикам. При этом, чем больший вклад вносят поставщики в итоговую ценность услуг, тем большее внимание провайдер должен уделять процессу Управления поставщиками услуг. Процесс Управления поставщиками должен включать в себя: 1. формирование и соблюдение политики работы с поставщиками; 2. формирование Базы поставщиков и договоров, управление ею; 3. категоризация поставщиков и контрактов, оценка рисков; 4. оценка и выбор поставщиков и контрактов; 5. ведение переговоров и заключение контрактов и соглашений; 6. обзор, пересмотр и прекращение контрактов; 7. управление поставщиками и их производительностью; 8. согласование и реализация услуг поставщиков, а также планов по их улучшению; 9. управление стандартными контрактами, терминами и условиями; 10. управление спорами, возникающими при ведении переговоров и заключении контрактов. За взаимоотношения с конкретными поставщиками должно отвечать назначенное лицо из персонала провайдера. Выделяют роль владельца процесса Управления поставщиками и Менеджера контрактов. В маленьких организациях эти роли часто объединяют. Управление поставщиками следит за тем, чтобы поставщики выполняли свои обязательства по контрактам - достигали целевых показателей в оговоренные сроки. Центральным репозитарием для хранения информации является База поставщиков и договоров. База поставщиков и договоров (Supplier and Contract Database или SCD) - база данных или структурированный документ, используемый для управления договорами поставщиков на протяжении всего их жизненного цикла. SCD содержит ключевые атрибуты всех договоров с поставщиками[1]. SCD должна формироваться вместе с четко определенными ролями и ответственностями, как показано на рис. 6.6. увеличить изображение Рис. 6.6. Процесс Управления поставщиками SCD должна включать следующее: 1. категорирование поставщиков и управление SCD (этап проектирования); 2. поиск и оценка новых поставщиков (этап проектирования); 3. установление взаимоотношений с новыми поставщиками (этап внедрения); 4. управление контрактами, поставщиками и их производительностью (этап эксплуатации); 5. обновление и завершение контрактов (этап эксплуатации). Далее мы рассмотрим основные деятельности в рамках Управления поставщиками: 1. оценка новых поставщиков и контрактов При выборе поставщиков услуг необходимо учитывать множество факторов, в частности предыдущие достижения и текущие возможности поставщика, а также отзывы о нем других организаций. Более того, в зависимости от типа взаимоотношений с поставщиками, может появиться множество других ключевых факторов для выбора. В связи с этим каждая организация должна иметь формализованные процессы и процедуры для оценки новых поставщиков и контрактов. Услуга может поддерживаться одним или несколькими поставщиками. При этом многие отношения с поставщиками могут характеризоваться как партнерские. То есть в настоящее время организации отходят от традиционного иерархического построения отношений с поставщиками, в которых поставщики всегда зависели от своих заказчиков. Отношения с поставщиками характеризуются следующим: 1. ориентация на стратегию - отношения выстраиваются в соответствии с культурой, ценностями и целями бизнеса, то есть в соответствии с его стратегией; 2. интеграция - тесная интеграция процессов двух организаций; 3. информационный поток - хорошо налаженный обмен информацией между процессами двух организаций; 4. взаимное доверие - взаимное доверие между организациями; 5. открытость - открытость в отношении производительности услуг, затрат и анализа рисков; 6. коллективная ответственность - команды, объединяющие сотрудников двух организаций, несут ответственность за текущую производительность и развитие сотрудничества в будущем; 7. общие риски и премии - соглашение о том, как будут распределены выгоды и сопутствующие риски. Отношения, основанные на перечисленных выше принципах, приносят выгоду обеим сторонам. Благодаря тесной интеграции поставщик может более быстро реагировать на потребности организации, а организация, соответственно, получает большую ценность от взаимодействия с поставщиком. Две стороны могут подстраивать свои IT инфраструктуры друг под друга, что также обеспечивает дополнительную эффективность услуг и снижение затрат. При этом каждый участник отношений должен четко понимать, чего ждет от него второй участник. Провайдер должен формализовать подход к выбору поставщиков. Он должен быть основан на таких факторах как значение услуги, предоставляемой поставщиком, риски и стоимость. Обязательным является проведение Анализа рисков перед заключением какого-либо соглашения. Анализ рисков должен рассмотреть все возможные риски: финансовые, потери репутации, операционные, правовые и т.п. Чем более полный и подробный контракт будет заключен, тем меньше споров и разногласий возникнет в дальнейшем. Обязательные части базового контракта: o основные условия и сроки - срок, на который заключается контракт, стороны, которые его заключают, охват, определения и коммерческий базис; o описание услуг - функциональность, предоставляемая услугами, их производительность, доступность, безопасность и т.п., а также ограничения, влияющие на производительность услуг и их предоставление; o нормы для услуг - метрики и способы измерения услуг, минимальные уровни производительности и качества. Обозначенные уровни должны быть четкими, достижимыми и измеряемыми, соответствовать приоритетам бизнеса и поддерживать целевые уровни SLA и SLR; o производственная нагрузка - объемы производства, к которым применимы нормы для услуг и отдельные границы ценового диапазона; o управленческая информация - информация, которую должен предоставить поставщик об операционной производительности. Необходимо, чтобы взаимоотношения строились на наиболее значимых метриках производительности услуг; o ответственности и зависимости - описание обязанностей организации и поставщика. Категорирование поставщиков и управление SCD Процесс управления поставщиками должен быть адаптивным и уделять больше времени и внимания наиболее важным для организации поставщикам. Для этого необходимо расставить приоритеты между поставщиками, то есть категорировать их. Лучше всего при этом оценить вклад поставщика, предоставляемую им ценность для бизнеса и риски, которые к нему относятся (рис. 6.7). Рис. 6.7. Категорирование поставщиков В соответствии с этим можно предложить следующие категории: 0. стратегические поставщики - взаимоотношения с такими поставщиками управляются на уровне руководства организации. Формируются долгосрочные контракты, и происходит обмен конфиденциальной информацией с поставщиками. Такие отношения требуют участия ресурсов этапов Проектирования и Построения стратегии, а также разработку Стратегии непрерывного улучшения. 1. тактические поставщики - взаимоотношения с такими поставщиками управляются на уровне менеджеров среднего звена. К тактическим поставщикам относятся те, кто вносит значимый коммерческий вклад и имеет тесные связи с бизнесом. Примером может стать поставщик, предоставляющий услуги по восстановлению серверов после аппаратных сбоев. 2. операционные поставщики - поставщики, предоставляющие операционные услуги и продукты. Взаимоотношения с такими поставщиками управляются менеджерами нижнего уровня и включают в себя нечастые, но регулярные контакты и обзоры производительности. Примером может стать поставщик интернет-хостинга для малоиспользуемого и малозначимого для бизнеса сайта. 3. товарные поставщики - поставщики, предоставляющие продукты с низкой ценностью или поставщики, услуги и продукты которых могут быть легко заменены альтернативами, предлагаемыми другими участниками рынка. Например, поставщики бумаги или оргтехники. Исходя из предложенной классификации, чем более специализированную услугу или продукт предоставляет поставщик, тем большее внимание ему должно быть уделено в рамках процесса Управления поставщиками. Если же поставщик предлагает стандартные услуги, то не имеет смысла тратить много времени и ресурсов на управление взаимоотношениями с ним, так как его можно легко заменить другим поставщиком. В основе выбора поставщиков услуг и их категорирования лежит четкое понимание того, что хочет получить бизнес от их продуктов и услуг. При этом очень важно построить корректную цепочку поставщиков. Не рекомендуется передавать какой-то бизнес-процесс на аутсорсинг одному поставщику, так как это порождает множество рисков. SCD предоставляет информацию о поставщиках, предлагаемых ими услуг и продуктов и детали заключенных с ними контрактов. Установление взаимоотношений с новыми поставщиками Добавление новых поставщиков и контрактов в SCD должно контролироваться процессом Управления изменениями. Это гарантирует оценку и понимание влияния, которое они окажут на бизнес и его процессы. При этом необходимо также участие Анализа рисков. Новые риски должны быть выявлены, оценены и взяты под управление. После того, как все данные собраны, они заносятся в SCD. Управление контрактами, поставщиками и их производительностью При взаимодействии организации и поставщика может возникнуть непонимание и спорные моменты. Поэтому обеим сторонам нужно стараться наладить связи друг с другом. ITIL вводит термин "официальные обзорные встречи". Во время этих встреч представители заказчика и поставщика встречаются и обсуждают вопросы сотрудничества, анализируют отчеты о производительности предоставляемых услуг и т.п. Обычно в обсуждаемые темы входит следующее: o соответствие производительности целевым показателям; o обзоры инцидентов и проблем; o обратная связь с бизнесом и пользователями; o ожидаемые глобальные изменения, которые могут повлиять (или точно повлияют) на услугу в следующий период; также неудавшиеся изменения и изменения, вызвавшие инциденты; o ключевые события для бизнеса в течение следующего периода; o планы по улучшению услуг. Помимо встреч хорошим источником информации о поставщике является анкетирование и опрос. Они могут выявить недостатки и достоинства поставщика, которые не отображаются в стандартных отчетах. Завершение и обновление контрактов Для того чтобы обеспечивать соответствие контракта изменяющимся потребностям бизнеса, его нужно периодически пересматривать и при необходимости обновлять. Обзоры контрактов должны включать следующее: o как хорошо контракт работает и подходит для использования в будущем; o какие изменения необходимы (услуги, продукты, контракты, целевые показатели, соглашения); o оценка взаимоотношений на будущее (рост, сокращение, изменение, завершение и т.п.); o коммерческая производительность контракта, обзоры и сравнение с конкурентами, уместность цены и необходимых ресурсов; o выбор будущего направления развития контракта; o методика управления контрактами и поставщиками[10]. Для сложных контрактов, заключающихся на длительный период времени, характерным является длительные переговоры перед заключением. Обе стороны заинтересованы в том, чтобы максимально долго не вносить изменения в контракт. Входами процесса Управления поставщиками являются: 1. информация от бизнеса - стратегии, планы, бюджет бизнеса, а также его текущие и будущие требования; 2. стратегия поставщиков и контрактов организации: типы используемых поставщиков и контрактов, политика использованиявозможностей поставщиков. Источником является этап Построения стратегии; 3. стратегии и планы поставщиков - детали бизнес-планов и стратегий поставщиков, информация о развитии технологий, информация о их текущем финансовом состоянии и т.п.; 4. контракты, соглашения и цели поставщиков; 5. информация о производительности поставщиков и контрактов; 6. информация от IT - стратегия, планы и бюджет IT; 7. вопросы производительности - информация от Управления инцидентами и проблемами, в том числе проблемы и инциденты, связанные с плохими контрактами и плохой производительностью; 8. финансовая информация - стоимость услуг поставщиков, их предоставления, контрактов и выгода, которую в итоге получит бизнес от взаимодействия. Сюда также входят финансовые планы и бюджет, вместе с затратами на восстановление в случае сбоев. 9. информация об услугах - информация от SLM процесса, с деталями услуг из Портфеля услуг и Каталога услуг, целевые показатели услуг, оговоренные в SLA, OLA, SLR 10. информация о взаимоотношениях бизнеса с услугами, вспомогательными услугами и технологиями[10]. Выходами процесса Управления поставщиками являются: 1. SCD - хранилище информации, необходимой для всех процессов в рамках Управления поставщиками услуг; 2. отчеты о производительности поставщиков и контрактов - эта информация используется на обзорных встречах для отображения качества услуг, предоставляемых поставщиками и контрактами; 3. отчеты об обзорных встречах; 4. Планы улучшения услуг поставщиков - отображают все действия по улучшению услуг, согласованные как поставщиками, так и заказчиками; 5. отчеты по результатам анкетирования. В качестве ключевых показателей эффективности могут выступать, например: 1. защищенность бизнеса от плохой производительности поставщиков или сбоев в обеспечении: o увеличение количества поставщиков, выполняющих требования контрактов; o уменьшение количества нарушений контрактов; 2. Соответствие показателей предоставляемых услуг требованиям бизнеса o увеличить количество обзоров услуг и контрактов; o увеличить количество целевых показателей поставщиков и контрактов, соответствующих целевым показателям в SLA и SLR. Деятельность по проектированию и развитию новых технологий не должна быть изолированной, так как влияет на другие услуги, системы управления, инструменты, архитектуры, процессы и т.п. Другими словами, проектирование должно учитывать не только требования к функциональной составляющей услуг и компонентов. Управленческие и операционные требования также должны лечь в основу построения дизайна для новых или измененных услуг. Основными рисками для Управления поставщиками являются недостаточность информации, плохо налаженный обмен информацией между поставщиками и бизнесом, некорректные или невыполнимые цели, нехватка ресурсов и финансового обеспечения. В этой лекции мы рассмотрели шесть ключевых процессов этапа Проектирования услуг, которые обеспечивают его необходимой информацией для проектирования новых или измененных услуг. Лекция 7: Внедрение как этап жизненного цикла услуг Аннотация: Внедрение услуг как этап жизненного цикла услуг: назначение, основные принципы, входы и выходы. Ключевые слова: цикла, transition, RFC, деятельность, единица, ПО, сборка, поддержка, KPI, подмножество, р азделы, реальная производительность, очередь, SDP, интеграция процессов управления, service package, ITIL, полезность, мера, значение, service, управление активами, ITSM 7.1. Внедрение как этап жизненного цикла услуг Многие инновации в бизнесе реализуются посредством проектов с участием IT. При этом не важно, речь идет о незначительных операционных улучшениях или глобальных событиях, связанных с преобразованием целого бизнеса, - в конечном итоге это приводит к изменению. В частности, использование новой или измененной услуги также является изменением для бизнеса. Этап Внедрения гарантирует то, что запланированные и спроектированные на предыдущих стадиях жизненного цикла услуги смогут достичь ожидаемых бизнесом и IT результатов на практике. Следует отметить, что в некоторой русскоязычной литературе этап Внедрения называется Преобразованием услуг, так как transition с английского переводится как перемещение/переход. Таким образом, этап Внедрения является чем-то вроде буфера для проверки услуг перед непосредственной эксплуатацией. Прежде чем говорить о Внедрении, необходимо определить основные термины в его контексте. Преобразование (Transition) - изменение в состоянии, соответствующее перемещению услуги или конфигурационной единицы из одной стадии жизненного цикла к следующей стадии. Релиз (Release) - набор аппаратного обеспечения, программного обеспечения, документации, процессов или других компонентов, которые необходимы для внедрения одного или нескольких согласованных изменений в услугах. Содержание каждого релиза управляется, тестируется и развертывается как отдельная сущность. Запрос на изменение (Request for Change или RFC) - формальное предложение на реализацию Изменения. RFC включает в себя детальное описание предложенного изменения, и может быть записано в бумажном или электронном формате. Тестирование (Test) - деятельность, которая верифицирует, что конфигурационная единица, услуга, процесс, и т.п., соответствует спецификации или согласованным требованиям. Сборка(Build) - деятельность по компоновке одной и более конфигурационных единиц для формирования части услуги. Термин Сборка также используется в отношении релиза, который утвержден для распространения. Например, Сборка сервера или Сборканоутбука. Развертывание (Deployment) - деятельность, отвечающая за перемещение нового или измененного оборудования, ПО, документации, процесса, и т.п., в среду промышленной эксплуатации. Поддержка в начале эксплуатации (Early Life Support) - поддержка, предоставляемая в отношении новой или измененной услуги в течение некоторого времени непосредственно после того, как услуга была введена в эксплуатацию. Во время Поддержки в начале эксплуатации поставщик услуг может пересматривать KPI, уровни услуги и наблюдаемые пороговые значения, а также задействовать дополнительные ресурсы для Управления инцидентами и Управления проблемами. Среда (Environment) - подмножество ИТ-инфраструктуры, которое используется в различных целях. Для сложных Сред есть возможность совместно использовать конфигурационные единицы, например Среды тестовой и промышленной эксплуатации могут использовать различные разделы на одном майнфрейме. Также используется в термине физической среды для обозначения помещения, кондиционирования, системы питания и т.п. Среда промышленной эксплуатации (Live Environment) - управляемая среда, содержащая конфигурационные единицы в режиме промышленной эксплуатации, используемые для предоставления услуг. Среда тестирования (Test Environment ) - контролируемая среда, используемая для тестирования конфигурационных единиц, сборок, услуг, Процессов и т.п. Среда сборки (Build Environment) - контролируемая среда, в которой собираются (компонуются) приложения, услуги и другие сборки перед их передачей в Среду тестирования или Среду промышленной эксплуатации. Приемка(Acceptance) - формальное соглашение, определяющее, что услуга, процесс, План или другой результат завершен, является правильным, надежным и отвечает установленным требованиям. Приемке обычно предшествует оценка или тестирование, приемка часто обязательна для перехода к выполнению следующего этапа проекта или процесса. Основные цели этапа Внедрения: • планирование/управление мощностями и ресурсами для комплектования, сборки, тестирования и запуска в промышленную эксплуатацию услуг, а также обеспечение функционирования услуг в соответствии с требованиями инвесторов и заказчиков; • построение точной и последовательной системы оценки мощности услуг и формирование перечня рисков прежде, чем новая или измененная услуга будет выпущена в промышленную эксплуатацию; • формирование набора активов услуг и конфигураций, которые попадают на этап Внедрения, и управление ими; • предоставление информации, необходимой для принятия решений о введении услуги в промышленную эксплуатацию после тестирования; • предоставление эффективных и повторяемых механизмов для сборки и инсталляции, которые могут быть использованы для развертывания релизов в среде промышленной эксплуатации и среде тестирования; • обеспечение управления, поддержки и корректной эксплуатации услуг в соответствии с требованиями, определенными на этапе Проектирования. Задачами этапа Внедрения являются: • определить ожидания заказчиков относительно того, как новая или измененная услуга поможет их бизнесу; • помочь в интеграции новой или измененной услуги в бизнес-процессы заказчиков; • уменьшить разницу между прогнозируемой и реальной производительностью; • уменьшить количество известных ошибок и рисков на этапе запуска новой или измененной услуги в промышленную эксплуатацию; • обеспечить то, что услугу можно будет использовать в соответствии с установленными для нее требованиями и ограничениями. Этап Внедрения предоставляет ценность для бизнеса тем, что: • улучшает способность адаптироваться к новым требованиям или обстоятельствам на рынке; • улучшает управление на уровне внедрения в рамках поглощений, разъединений компаний, приобретения или перемещения услуг; • увеличивает количество успешных для бизнеса изменений и релизов; • улучшает точность прогнозирования относительно уровня и качества новых или измененных услуг; • улучшает согласованность с требованиями бизнеса и руководства; • уменьшает количество расхождений между утвержденными бюджетами/планами и реальностью; • увеличивает продуктивность персонала вследствие улучшения планирования и использования новых или измененных услуг; • уменьшает случаи временной приостановки или изменения контрактов на программное и аппаратное обеспечение вследствие соединения или разъединения компонентов; • улучшает понимание уровня риска во время изменения и после него. Этап Внедрения находится между этапами Проектирования и Эксплуатации в жизненном цикле услуг. Именно с этими этапами происходит наиболее тесное и непрерывное взаимодействие. Тем не менее, у этапа Внедрения есть связи со всеми другими этапами жизненного цикла услуг. Входы, поступающие с этапа Построения стратегии, влияют на подход, структуры и ограничения этапа Внедрения: 1. Портфель услуг; 2. Портфель заказчиков - база данных или структурированный документ, используемый для хранения информации обо всех Заказчиках поставщика услуг; 3. Портфель договоров - база данных или структурированный документ, используемый для управления договорами на оказание услуг или Соглашениями между поставщиками услуг и их заказчиками[1]; 4. модель жизненного цикла услуги; 5. политики; 6. стратегии; 7. ограничения; 8. архитектуры; 9. требования к Внедрению; 10. План управления услугами. Этап Проектирования услуг является источником триггеров (или механизмов запуска) для этапа Внедрения. В первую очередь это проектная документация (SDP), которую необходимо реализовать. Она включает в себя следующие компоненты: 1. определение услуги; 2. структура услуги; 3. финансовая модель и модель затрат; 4. модель мощностей/ресурсов; 5. модель интеграции процесса Управления услугами; 6. модель эксплуатации услуги; 7. спецификация дизайна и интерфейса; 8. дизайн релиза; 9. критерии приемки; 10. Запросы на изменения (RFC). Этап Непрерывного улучшения услуг предоставляет на вход этапа Внедрения информацию в терминах предлагаемых улучшений политик, практик и процессов внедрения. Этап Эксплуатации предоставит на вход этапа Внедрения информацию для тестирования и приемки услуг в терминах достижения услугами требуемых показателей. Выходами этапа Внедрения являются: 1. утвержденная документация для релиза и развертывания услуг; 2. обновленный Пакет Услуг. Пакет услуг (Service Package) - детализированное описание услуги, доступной для предоставления заказчикам[1]; 3. обновленные Каталог услуг и Портфель услуг; 4. документация для внедряемых или списываемых услуг. В ITIL выделено два типа процессов этапа Внедрения: 1. процессы, поддерживающие жизненный цикл услуги: o Управление изменениями; o Оценка услуг и Управление конфигурациями; o Управление знаниями. 2. процессы в рамках Внедрения: o Планирование и поддержка Внедрения; o Управление релизами и развертыванием; o Тестирование и подтверждение услуг; o Оценка. Этап Построения стратегии предоставляет систему для определения услуги. Ценность услуги определяется в контексте потребностей заказчика. Использование активов поставщика услуг для предоставления услуг бизнесу и заказчикам представлено на рис. 7.1. увеличить изображение Рис. 7.1. Активы, необходимые для предоставления услуг Здесь под активами понимаются ресурсы и возможности поставщика услуг. Услуги предоставляют ценность посредством увеличения производительности активов бизнеса или уменьшения рисков. Как уже отмечалось ранее, ценность услуги выражается в терминах качества и полезности. Полезность - мера увеличения производительности активов заказчика. Качество уверенность в том, что услуга в процессе предоставления будет выполнять ряд установленных условий. Выделяют три основные характеристики качества услуг: • доступность и мощность услуг; • обеспечение того, что активы заказчика будут получать полезность, даже в случае неблагоприятных событий или сниженного уровня услуг; • обеспечение безопасности для наиболее ценных активов заказчика. При этом в зависимости от конкретной ситуации один из аспектов качества может иметь большее значение для заказчика. 7.2. Основные принципы этапа Внедрения Приведем фундаментальные принципы этапа Внедрения из публикации "ITILv3. Service Transition". 1. Определение и осуществление формальной Политики Внедрения Позиция: Формальная Политика Внедрения должна быть определена, документирована и утверждена руководством. Ее необходимо довести до всех сотрудников организации, поставщиков и партнеров, которые имеют отношение к Внедрению. Принципы: 1. в политике должны быть четко определены цели, а любые несовпадения с политикой должны быть исправлены, либо исключены; 2. необходимо обеспечить соответствие Политики Внедрения политикам Управления услугами; 3. люди, ответственные за формирование политики, должны демонстрировать свою заинтересованность в ее выполнении; 4. использовать процессы, которые объединяют команды; смешивать компетенции в рамках ведения отчетности и распределения ответственностей; 5. предоставлять изменения в релизах; 6. затрагивать вопросы развертывания уже на этапах планирования и проектирования релизов. Лучшие практики: Получать формальные подписи тех, кто участвует в разработке Политики: менеджеров, спонсоров и других людей, которые принимают решения. 2. Осуществление изменений в услугах через Внедрение Позиция: Все изменения, касающиеся Портфеля услуг и Каталога услуг, проходят через процесс Управления изменениями. При этом все изменения должны быть четко определены и согласованы. Принципы: 1. концентрирование изменений в одной точке минимизирует конфликты между изменениями, последующие нарушения и сбои в среде промышленной эксплуатации; 2. люди, которые не имеют прав вносить изменения и выпускать услуги в промышленную эксплуатацию, не должны иметь доступ к процессам Внедрения; 3. тесное взаимодействие с этапом Эксплуатации повысит мобильность и сделает возможным организационные изменения; 4. увеличение знаний и опыта в вопросах эффективного улучшения услуг и среды промышленной эксплуатации; 5. каждый релиз должен быть спроектирован на основе Запроса на изменение и пройти сквозь процесс Управления изменениями, что обеспечит эффективный контроль; 6. для управления изменениями необходимо использовать стандартизованные методы и процедуры с целью уменьшения влияния инцидентов, связанных с изменениями, на непрерывность бизнеса, качество услуг и доработки; 7. все обновления для изменений и релизов фиксируются в контексте активов услуг и конфигурационных единиц в Системе Управления Конфигурациями(CMS). Лучшие практики: o каждое изменение должно быть четко определено; o необходимо разделять внутренние и внешние изменения; o изменения должны быть оправданы с помощью четкого бизнес-кейса; o изменения определены в проектной документации, которую Внедрение может использовать для сравнения производительности, полученной на практике, и "предсказанной" в документации; o существующий процесс Управления изменениями, возможно, придется стандартизовать и приводить в исполнение; o менеджеры должны участвовать в процессах и это должно быть четко видно инвесторам; o настройка аудита для идентификации всех неавторизованных изменений; o не принимать "запоздавшие" запросы на изменения, которыми невозможно управлять надлежащим образом. Разработка общей структуры и стандартов Внедрения Позиция: Внедрение должно быть построено на стандартных процессах и системах, допускающих многократное пользование. Это позволит улучшить интеграцию отдельных подэтапов Внедрения и уменьшить несогласованность процессов. Принципы: 0. использовать лучшие практики конкретной области как основу для стандартизации Внедрения; 1. контролировать структуру и стандарты Внедрения с помощью Управления изменениями и Управления конфигурациями; 2. гарантировать то, что процессы Внедрения применяются последовательно с регулярными обзорами и аудитами других процессов Управления услугами. Лучшие практики: o публикация стандартов и лучших практик Внедрения; o построение системы для создания последовательных процессов по обеспечению и использованию мощности услуг и построение перечня рисков до и после того как релиз развернут; o предоставить поддерживающие системы, которые позволят автоматизировать процессы с целью уменьшения сопротивления при внедрении; o убедиться в том, что менеджмент понимает необходимость стандартизации процессов в рамках разработки и предоставления улучшений, основанных на четком бизнес-кейсе; o установить уровень вовлеченности менеджмента и инвесторов и предпринять действия по устранению любых "разрывов". Максимальное повторное использование процессов и систем Позиция: Процессы этапа Внедрения должны быть согласованы с процессами организации и связанными с ними системами. Если появляется необходимость в новых процессах, они разрабатываются с максимальным повторным использованием уже имеющихся процессов. Принципы: 0. повторное использование имеющихся процессов и систем там, где это возможно; 1. сбор информации и данных из оригинальных источников с целью уменьшения ошибок и эффективной помощи в случае возникновения необходимости; 2. разработка стандартных моделей Внедрения, которые можно многократно использовать; 3. использование лучших стандартов и практик области в качестве основы для стандартизации с целью объединения результатов от разных поставщиков. Лучшие практики: o интегрировать процессы Внедрения в систему управления качеством; o использовать управленческие практики и общую программу организации; o использовать существующие каналы связи для обеспечения коммуникации в рамках Внедрения; o следовать процессам Управления человеческими ресурсами, финансами, ресурсами, возможностями и общепринятым практикам; o структурировать модели так, чтобы постоянный подход можно было использовать для каждой единицы услуги или окружения с незначительными изменениями при необходимости. Формирование планов Внедрения в соответствии с требованиями бизнеса Принцип: С целью максимизации ценности, предоставляемой изменением, необходимо обеспечить соответствие планов Внедрения требованиям бизнеса и заказчиков. Принципы: 0. сформировать набор ожиданий заказчиков и пользователей относительно производительности и использования новой или измененной услуги на этапе Внедрения; 1. предоставить информацию и процессы для интеграции релиза в бизнес-процессы; 2. с целью повышения удовлетворенности заказчиков обеспечить использование услуги в соответствии с определенными для нее требованиями и ограничениями; 3. с целью максимизации использования услуги заказчиками, инвесторами и пользователями обеспечить их необходимой информацией и знаниями; 4. обеспечить мониторинг и измерение использования услуг, поддерживающих их приложений и технических решений в процессе развертывания и на ранних стадиях поддержки. Это необходимо для того, чтобы гарантировать качественное предоставление услуг прежде, чем этап Внедрения будет завершен; 5. сравнить производительность услуг, полученной на практике, с запланированной на стадии Построения стратегии, и провести мероприятия по сокращению несоответствий в показателях мощности и производительности. Лучшие практики: o использовать лучшие управленческие практики для планирования и управления ресурсами, необходимыми для успешной сборки, комплектования, тестирования и развертывания релиза в промышленную эксплуатацию в рамках установленных затрат, времени и качества; o предоставить четкие, понятные и полные планы, которые обеспечат соответствие проектов изменений бизнеса и заказчиков и планов Внедрения. o управлять вовлеченностью инвесторов и связью с ними. Установление и управление взаимоотношениями с инвесторами Позиция: Для формирования набора требований к новой или измененной услуге в рамках Внедрения необходимо установить и управлять взаимоотношениями с заказчиками, их представителями, инвесторами и поставщиками. Принципы: 0. сформировать набор ожиданий заинтересованных сторон о том, как производительность и использование новой услуги могут помочь изменению бизнеса; 1. улучшать понимание и знания заинтересованных сторон о новых или измененных услугах; 2. предоставлять качественную информацию и накопленный опыт заинтересованным сторонам, чтобы они могли легко получить всю необходимую им информацию о Внедрении. Лучшие практики: o проверить вместе с заинтересованными сторонами то, что новая или измененная услуга может использоваться в соответствии с установленными требованиями и ограничениями; o обмениваться планами Внедрения и релизов с заинтересованными сторонами; o работать вместе с Управлением отношениями с бизнесом и Управлением уровнем услуг для построения взаимоотношений с заказчиками и инвесторами в рамках этапа Внедрения. Установление эффективных контролей и дисциплин Позиция: Установление подходящих контролей и дисциплин в рамках жизненного цикла услуг, которые сделают возможным гладкое внедрение изменений и релизов услуг. Принципы: 0. идентификация и управление всеми активами услуг и конфигурациями с момента их поступления на этап Внедрения; 1. автоматизация деятельности по аудиту там, где это экономически оправдано, с целью обнаружения неавторизованных изменений и несовместимости конфигураций; 2. четко определение того, "кто, где, что и когда делает" в рамках внедрения, для увеличения подотчетности в отношении планов и процессов; 3. определение ролей и ответственностей в рамках Внедрения с целью уменьшения ошибок, появляющихся из-за взаимного непонимания и недостатка контроля; 4. идентификация процессов, основанных на транзакциях, для управления конфигурациями, изменениями и проблемами с целью предоставления информации, необходимой для улучшения контролей. Лучшие практики: o убедиться в том, что роли и ответственности хорошо определены, понятны и управляемы; o назначить людей на каждую роль и управлять назначениями в рамках SKMS или CMS, чтобы предоставить прозрачность о том, кто ответственен за конкретную деятельность; o использовать интегрированные процессы управления инцидентами, проблемами, конфигурациями для измерения качества конфигурационных единиц в рамках жизненного цикла услуг; o гарантировать то, что услуга может использоваться, управляться и поддерживаться в соответствии с требованиями и ограничениями, определенными на этапе Построения стратегии; o убедиться в том, что только компетентный персонал может производить изменения; o проводить аудит процессов и конфигураций с целью обнаружения несоответствий и нарушений, которые могут негативно повлиять на этап Внедрения. Предоставление обмена знаниями и поддержки решений Позиция Этап Внедрения разрабатывает системы и процессы обмена информацией для эффективного использования услуги. Обмен информацией также обеспечивает своевременное принятие решений компетентными людьми. Принципы: 0. предоставлять качественную информацию, данные и знания "нужным людям в нужное время" с целью уменьшения времени для принятия решений; 1. осуществлять обучение пользователей и передачу им необходимой информации с целью уменьшения количества обращений в сервис-деск; 2. повышать качество информации и данных для увеличения удовлетворенности заказчиков и инвесторов при одновременной оптимизации затрат на производство и поддержку; 3. повышать качество документации, относящейся к этапу Внедрения; 4. обеспечить легкий доступ к информации, чтобы те, кому она необходима, не тратили время на долгий поиск. Особенно актуально в отношении критических деятельностей, таких как управление в случае крупных инцидентов. 5. определить единый источник информации, который позволит обмениваться ей в рамках жизненного цикла и с инвесторами с целью обеспечения максимального качества информации и облегчения управления ею; 6. предоставлять полную информацию процессам Управления релизами, изменениями и разработкой, дабы они могли принимать решения о передаче релиза на тестирование или эксплуатацию. Лучшие практики: o предоставление доступа, презентаций и инструментов отчетности для Системы управления знаниями по услугам (SKMS) и Системы управления конфигурациями (CMS); o предоставление удобных интерфейсов доступа к SKMS и CMS для разных людей и ролей, чтобы они могли своевременно принимать необходимые решения; o объединение и публикация предсказуемых и непредсказуемых эффектов изменения, различия актуальной и предсказываемой производительности и мощности, формировать перечень рисков; o убедиться в корректности информации от Управления конфигурациями и Управления активами; o предоставление данных, информации и знаний, необходимых для разрешения проблемных ситуаций (инцидентов и ошибок). Планирование пакетов для релиза и развертывания Позиция: Пакеты для релизов должны быть спланированы и спроектированы так, чтобы их сборка, тестирование, предоставление и передача в промышленную эксплуатацию осуществлялись на согласованных уровнях эффективности, отчетности и затрат. Принципы: 0. политика релизов должна быть согласована с бизнесом и всеми другими участниками Внедрения; 1. планирование релизов необходимо производить заблаговременно; 2. использование ресурсов должно быть оптимизировано в рамках Внедрения; 3. необходимо планировать механизмы выпуска и распространения услуг так, чтобы обеспечить целостность компонентов в рамках этапов Внедрения; 4. оценка и управление рисками изъятия или исправления ошибочных релизов; 5. необходимо измерять "успех и неудачи" релизов с целью дальнейшей оптимизации затрат и увеличения эффективности. Лучшие практики: o все обновления релизов должны быть отображены в Системе управления конфигурациями (CMS); o необходимо фиксировать даты релизов и развертывания вместе с относящимися к ним запросами на изменение и проблемами; o процедуры, используемые для управления, развертывания, предоставления, публикации и распространения, должны быть отработаны и проверены: o информация о том, что необходимо для релиза, должна доходить до соответствующих участников процесса Внедрения в виде документов, например, технические требования для среды тестирования. Управление изменениями курса Позиция: Внедрение является длительным и трудоемким процессом, на который влияет множество факторов. Участники должны быть способны распознавать ситуации и обстоятельства, при которых требуется смена или корректировка курса Внедрения. Целью Управления изменениями курса является обучение персонала тому, как распознавать необходимость корректирующих мер и вносить предложения на изменение курса с учетом существующих ограничений. Принципы: 0. способствовать тому, чтобы инвесторы понимали необходимость изменений планов и принимали в них участие; 1. использовать опыт предыдущих коррекций с целью предсказания их необходимости в будущем и повторного использования успешных подходов; 2. собирать информацию от завершенных внедрений и делать ее доступной; 3. управлять изменением курса с помощью Управления изменениями и других подходящих процедур в рамках жизненного цикла услуг. Лучшие практики: o для управления изменениями курса необходимо использовать практики менеджмента и процесса Управления изменениями; o документировать и контролировать все изменения, но без лишней "бюрократии"; o предоставлять информацию об изменениях, которые были применены после соответствующей настройки конфигураций; o при необходимости вовлекать инвесторов в изменения. Проактивное управление ресурсами в рамках Внедрения Позиция: Предоставлять и распределять ресурсы в рамках Внедрения так, чтобы избежать любых задержек. Принципы: 0. определить ресурсы, информацию и навыки, необходимые для осуществления Внедрения; 1. сформировать команду, способную успешно реализовать стратегию Внедрения, проектную документацию и пакет релиза; 2. выделять ресурсы, необходимые для критических деятельностей в рамках Внедрения, с целью предотвращения задержек в их предоставлении; 3. автоматизировать процессы, которые часто повторяются или подвержены ошибкам со стороны персонала, с целью повышения эффективности деятельностей в рамках Внедрения. Лучшие практики: o взаимодействие с управлением персоналом, поставщиками и т.п., с целью определения, управления и использования доступных и подходящих ресурсов; o определение необходимых ресурсов, которые находятся за пределами ITSM, и их использование; o проактивное управление распределением ресурсов с целью минимизации негативного влияния задержки в одном внедрении на другое. Участие на ранних стадиях жизненного цикла услуги Позиция: Необходимо контролировать услугу на ранних стадиях жизненного цикла с целью проверки ее способности предоставлять требуемую ценность. Принципы: 0. использовать различные способы для обнаружения ошибок и сбоев на ранних этапах жизненного цикла услуги. Чем раньше они будут выявлены, тем дешевле будет их устранить; 1. идентифицировать изменения, которые не принесут ожидаемой выгоды, и остановить их до того, как ресурсы будут использованы впустую. Лучшие практики: o вовлекать заказчиков и их представителей в процесс тестирования, чтобы понять, как можно доказать им, что услуга принесет для них выгоду; o вовлекать пользователей в тестирование там, где это возможно, чтобы проверить, как они будут использовать услугу на практике; o использовать предыдущий опыт для определения возможных ошибок проектирования; o предусмотреть и встроить в услугу механизмы, которые позволят контролировать ценность услуги и показывать ее заказчику; o использовать независимые оценку и аудит для установления приемлемости рисков. Гарантировать качество новой или измененной услуги Позиция: Проверять и утверждать предложенные изменения услуг с целью гарантии того, что они удовлетворят требования заказчиков и принесут им выгоду. Принципы: 0. Внедрение должно гарантировать, что предложенные изменения услуг могут быть осуществлены в соответствии с планами, спецификациями и соглашениями в рамках согласованных уровней услуг; 1. убедиться, что команды, вовлеченные в процесс Внедрения, действительно понимают, что пользователи и заказчики хотят получить в результате использования услуг; 2. оценка качества и тестирование должны предоставить комплексную оценку качества новой или измененной услуги, и сопровождающих ее рисков; 3. среда для тестирования должна максимально отражать среду эксплуатации; 4. проектирование и проведение тестирования должны быть максимально независимы от проектировщиков и разработчиков с целью повышения эффективности и разделения обязанностей; 5. осуществлять процессы Управления конфигурациями и Управления проблемами в рамках жизненного цикла услуг с целью измерения и уменьшения известных ошибок, вызванных передачей релизов в промышленную эксплуатацию. Лучшие практики: o понимать приоритеты и процессы бизнеса; o стараться вовлекать все заинтересованные стороны в процессы Внедрения с целью формирования у них доверия; o понимать разницу межу средами тестирования, сборки и рабочей эксплуатации для того, чтобы управлять любыми отличиями и прогнозировать поведение услуги в той или иной ситуации; o оборудование для тестирования должно управляться в рамках Управления изменениями и конфигурациями; o отправной точкой для реализации изменения должна быть информация о текущем состоянии услуги и информация, поступающая с этапа Проектирования; o до публикации и распространения услуги необходимо оценить производительность, качество и затраты, которые были спрогнозированы на этапе Проектирования, в контексте предыдущего опыта и обратной связи с инвесторами; o учитывать обстоятельства и условия, которые будут присутствовать на практике после завершения Внедрения. Проактивное улучшение качества в процессе Внедрения Позиция: Проактивное планирование и улучшение новой или измененной услуги в процессе Внедрения. Принципы: 0. обнаружение и устранение инцидентов и проблем на этапе Внедрения с целью уменьшения вероятности их возникновения на этапе Эксплуатации; 1. проактивное обнаружение и управление инцидентами, проблемами и ошибками на этапе Внедрения, с целью уменьшения затрат, количества доработок и негативного влияния на бизнес; Лучшие практики: o сравнивать значения мощности, производительности и затрат, полученные на практике, с теми, которые были предсказаны на предыдущих этапах жизненного цикла, с целью устранения расхождений до завершения этапа Внедрения; o проводить независимую оценку новой или измененной услуги с целью построения перечня рисков, их категорирования и минимизации/устранения до завершения этапа Внедрения; o использовать перечень рисков для тестирования; o предоставить инструменты поддержки и диагностики, которые в случае возникновения проблем на этапе эксплуатации или тестирования позволят быстро найти и устранить проблему; o обеспечить обмен информацией между Внедрением и Эксплуатацией с целью уменьшения времени диагностики и решения проблем; o фиксировать известные ошибки и устранять инциденты в соответствии с их приоритетами; o проактивный анализ основных причин повторяющихся и критичных инцидентов; o классификация, измерение и документирование количества проблем и инцидентов в рамках каждого релиза и их негативного влияния с целью выявления возможностей по устранению ошибок; o сравнивать количество и степень негативного влияния проблем и инцидентов между различными развертываниями с целью идентификации улучшений и разрешения основных проблем; o информировать Управление инцидентами и Управление проблемами обо всех исправлениях и проблемах в рамках Внедрения. Лекция 8: Планирование Внедрения. Управление изменениями, активами и конфигурациями в рамках Внедрения Аннотация: Процессы и деятельности в рамках этапа Внедрения услуг: цель, входы и выходы, основные деятельности и ключевые показатели эффективности. В лекции рассматриваются следующие процессы: Планирование и поддержка Внедрения. Управление изменениями, Управление активами и конфигурациями. Ключевые слова: service, transition, поддержка, операционные требования, SDP, координация, распределение ресурсов, цикла, улучшение, Backup, запрос, группа, change, ITIL, запись, жизненный цикл, информация, множества, RFC, категорирование, менеджмент, очередь, график, процесс управления, представление, доступ, PSO, управление активами, прибыль, определение, контроль, единица, компонент, программное обеспечение, SLA, совокупные активы, CMS, контекст, ссылка, деятельность, база данных, критерии выбора, механизмы, значимость, корректность, идентификация активов В ближайших лекциях мы рассмотрим процессы, которые составляют основу этапа Внедрения услуг. Процессы, деятельности в их рамках и взаимосвязи показаны на рис. 8.1. увеличить изображение Рис. 8.1. Процессы в рамках Внедрения Некоторые из представленных процессов выходят за рамки этапа Внедрения. Тем не менее, они рассматриваются в публикации "ITILv3. Service Transition", так как лежат в основе Внедрения. Далее мы рассмотрим цели, охват, деятельности и другие параметры и составляющие процессов, представленным на рис. 8.1. 8.1. Планирование и поддержка Внедрения Основные цели Планирования и поддержки Внедрения: 1. планирование ресурсов и мощностей, необходимых для комплектования, сборки, тестирования, публикации, развертывания и вывода новых или измененных услуг в промышленную эксплуатацию; 2. предоставление поддержки для персонала в рамках Внедрения; 3. планирование изменений, необходимых для эффективного управления активами заказчиков, активами услуг и конфигурациями; 4. ведение отчетности обо всех проблемах, рисках и расхождениях перед заинтересованными сторонами и теми, кто ответственен за принятие решений; 5. координация проектов, поставщиков и контрактов, поддерживающих услуги. Планирование и поддержка Внедрения включает в себя: 1. учет операционных требований и требований проектирования в планах Внедрения; 2. управление деятельностями в рамках Внедрения; 3. управление процессами, рисками и расхождениями в рамках Внедрения; 4. качественный пересмотр планов Внедрения, развертывания и релиза услуг; 5. взаимодействие с заказчиками, пользователями и другими заинтересованными сторонами в вопросах, касающихся внедрения; 6. мониторинг и улучшение производительности Внедрения как процесса. Внедрение требует внимательного подхода и последовательных действий. Первое, что необходимо определить - Стратегия Внедрения. Она определяет общий подход организации к внедрению и должна рассматривать следующее: • цели Внедрения; • контекст внедрения (заказчики, договора и т.п.); • охват - то, что входит и не входит в рамки Внедрения; • применяемые стандарты, соглашения, требования регуляторов и контрактов; • организации и инвесторы, вовлеченные во Внедрение; • структура Внедрения: o применяемые политики, процессы и практики; o роли и ответственности; o распределение ресурсов в рамках Внедрения; o формирование требований к подготовке и обучению; o механизм авторизации для доступа к релизам и изменениям; o использование накопленного опыта, практики и данных; o распределенные ресурсы и услуги, поддерживающие Внедрение; • критерии успеха для каждой стадии Внедрения, а также остановки или перезапуска деятельностей в рамках Внедрения; • определение требований и содержания новой или измененной услуги в контексте Внедрения; • персонал - назначение на роли, обучение и т.п.; • подход к Внедрению: o модель Внедрения; o планы управления изменениями, активами, конфигурациями и знаниями; o планирование затрат, ресурсов и оценочных работ; o подготовка к Внедрению; o оценка; o комплектование, сборка, развертывание и ранняя поддержка релиза; o контроль и управление проблемами, ошибками, инцидентами и т.п. o мониторинг процессов и формирование отчетности; o система измерения производительности услуг; o • ключевые показатели производительности и цели по улучшению. выходы деятельностей в рамках Внедрения, в том числе документация[16]. Второй стадией является подготовка к Внедрению. На этой стадии проверяются и собираются все входы процессов, наличие необходимых конфигураций и общая готовность к Внедрению. В частности, детально рассматривается проектная документация (SDP), поступившая с этапа Проектирования. Именно она во многом определяет Внедрение. Следующая стадия - планирование и координация Внедрения. План Внедрения описывает задачи и действия, необходимые для передачи релиза на тестирование или промышленную эксплуатацию. Одним из основных вопросов является распределение ресурсов для конкретных деятельностей в рамках Внедрения. Набор планов внедрения находится между Стратегией внедрения и планами низших уровней планами релизов, сборки, тестирования и т.п. Далее необходимо обеспечить поддержку Внедрения. Сюда относятся вопросы взаимодействия со всеми заинтересованными лицами, мониторинга производительности услуг и обеспечение обратной связи с другими этапами жизненного цикла. Формирование отчетности о ходе процессов и доведение ее до руководства и заинтересованных лиц позволит сделать выводы о соответствии планам, стратегиям и стандартам, а также эффективности Внедрения в целом. Таким образом, основными выходами процесса Планирования и поддержки Внедрения являются Стратегия Внедрения и набор планов Внедрения. Ключевые показатели производительности процесса: • количество релизов, которые соответствуют согласованным требованиям заказчиков по затратам, качеству, охвату и временным рамкам; • уменьшение несоответствия между тем, что получается на практике, и тем, что планировалось; • увеличение удовлетворенности пользователей и заказчиков планами и коммуникациями, которые позволяют настраивать бизнес-деятельность в соответствии с планами Внедрения; • уменьшение количества рисков, вопросов и задержек, вызванных некорректным планированием. 8.2. Управление изменениями Изменения являются важной составляющей любого бизнеса. Они могут быть проактивными и реактивными. Проактивные направлены на улучшение бизнеса, например, уменьшение издержек или увеличение эффективности поддержки. Реактивные являются ответными действиями на возникающие обстоятельства. Чаще всего осуществление реактивных изменений связано с адаптацией бизнеса к изменяющимся обстоятельствам. Изменение может иметь различную трактовку в зависимости от контекста. Изменение услуг добавление, модификация или удаление утвержденной, запланированной или поддерживаемой услуги или ее компонента и соответствующей документации. Управление изменениями охватывает изменения в основных активах услуг и конфигурационных единицах в течение всего жизненного цикла услуг. Управление изменениями необходимо по следующим причинам: 1. оптимизация рисков; 2. минимизация негативного влияния на бизнес со стороны ошибок и сбоев; 3. успешная реализация изменений с первой попытки. Основными целями Управления изменениями является обеспечение: • использования стандартных методов и процедур для быстрой и эффективной реализации изменений; • фиксации всех изменений в активах услуг и конфигурациях в Системе Управления конфигурациями (CMS); • оптимизации всех рисков для бизнеса. На рис. 8.2 представлен охват процесса Управления изменениями. увеличить изображение Рис. 8.2. Охват Управления изменениями Стратегические изменения поступают с этапа Построения стратегии или от процессов управления бизнес-отношениями. Тактические изменения услуг поступают от этапа Проектирования, Непрерывного улучшения услуг и от процессов управления на уровне услуг. Корректирующие изменения, исправление ошибок в существующих услугах - от этапа Эксплуатации. Управление изменениями представляет ценность для бизнеса тем, что: 1. категорирует цели изменений бизнеса и заказчиков и помогает их осуществить; 2. реализует изменения, которые соответствуют потребностям заказчиков, одновременно с оптимизацией затрат; 3. старается выполнять требования закона, контрактов, руководства и регуляторов; 4. уменьшает количество неудавшихся изменений и, соответственно, количество сбоев, остановок и простоев услуг; 5. осуществляет изменения в установленном бизнесом временном интервале; 6. следит за изменениями на всем жизненном цикле услуг; 7. старается обеспечить лучшие показатели в аспектах качества, времени и затрат; 8. оценивает риски, сопутствующие внедрению; 9. помогает увеличить продуктивность работы персонала тем, что минимизирует нарушения и сбои, а, следовательно, улучшает доступность услуг; 10. уменьшает Среднее время восстановления услуг (MTRS) посредством быстрой и успешной реализации изменений; 11. сотрудничает с процессом изменения бизнеса для выявления возможностей улучшения бизнеса. Хорошо структурированные и запланированные изменения помогают бизнесу сократить издержки и повысить эффективность. Модель процесса изменения должна включать следующее: 1. шаги, которые должны быть предприняты для реализации изменения, в том числе разрешение проблем и непредвиденных событий; 2. хронологический порядок шагов; 3. ответственности и распределение обязанностей; 4. границы, в том числе временные, каждой деятельности в рамках процесса; Ни одно изменение не должно осуществляться без четкого планирования действий в случае, если оно будет неудачным - "планирование исправления". В идеале должен быть некий план "backup", который позволит организации вернуться в состояние, предшествующее изменению. Только посредством оценки того, какие действия по исправлению возможны в конкретной ситуации, можно определить риски, соответствующие изменению. Деятельности в рамках Управления изменениями включают: 1. планирование и контроль изменений; 2. составление расписаний для изменений и релизов; 3. обеспечение коммуникации между всеми участниками и компонентами; 4. авторизация к изменениям (то есть разрешения доступа тем, кто уполномочен вносить изменения) и принятие решений относительно изменений; 5. формирование планов по исправлению, которые будут задействованы в случае неудачных изменений; 6. измерение и контроль; 7. формирование управленческой отчетности; 8. оценка влияния изменения; 9. непрерывное улучшение. Стандартные действия при реализации отдельных изменений: • создание Запроса на изменение(RFC); • пересмотр и проверка RFC, фильтрация изменений; • оценка и определение изменения: o установить уровень управления изменением; o определить участников процесса; o оценить мотивацию бизнеса, издержки, риски и выгоды, связанные с изменением; o запросить независимую оценку изменения. • утверждение изменения (в том числе определение механизмов авторизации к нему); • формирование планов обновлений; • координация реализации изменения; • обзор и завершение изменения. На рис. 8.3 показан процесс реализации стандартного изменения. Рис. 8.3. Процесс реализации стандартного изменения Рассмотрим подробнее действия в рамках реализации стандартного изменения. Запрос на изменение создается инициатором, в качестве которого может выступать отдельный человек или группа людей. Если требуется значительное изменение, может потребоваться Предложение изменения (Change Proposal). Предложение изменения должно содержать в себе детальную информацию об изменении, обоснование его необходимости (в том числе экономическое). Все полученные запросы на изменения должны быть зарегистрированы, в терминологии ITIL у каждого изменения должна быть запись. Запись об изменении (Change Record) - запись, содержащая детальную информацию об изменении. Каждая запись об изменении документирует жизненный цикл одного изменения. Запись об изменении создается для каждого полученного Запроса на изменение, даже если он впоследствии отклонен (отвергнут). Запись об изменении должна содержать информацию о конфигурационных единицах, которые затрагивает данное изменение. Записи об изменениях хранятся в Системе управления конфигурациями[1]. Формат записи определяется на этапах планирования и проектирования. Информация, которую содержит запись об изменении, зависит от множества факторов: модель процесса реализации изменения, категория изменения и т.п. В рамках пересмотра RFC Управление изменениями рассматривает каждое изменение и отфильтровывает непрактичные, некорректно обоснованные и т.п. изменения. Для того чтобы оценить изменение ITIL предлагает ответить на 7 вопросов: 1. кто инициировал изменение? 2. какова причина изменения? 3. какой результат ждут от реализации изменения? 4. какие риски связаны с изменением? 5. какие ресурсы необходимы для реализации изменения? 6. кто ответственен за реализацию изменения? 7. какие связи изменение имеет с другими изменениями? В рамках оценки изменения необходимо определить следующее: • влияние, которое окажет изменение на операционную деятельность бизнеса; • влияние, которое окажет изменение на инфраструктуру и услуги заказчика; • влияние на другие услуги, которые используют ту же инфраструктуру; • влияние на инфраструктуры, не связанные с IT (например, транспортную, систему безопасности и т.п.); • что будет, если не реализовать изменение; • ресурсы, необходимые для реализации изменения - затраты, персонал, время и новые элементы инфраструктуры; • текущий график изменений и ожидаемый простой услуги. График изменений (Change Schedule) - документ, в котором перечислены все утвержденные изменения и их плановые сроки внедрения. Ожидаемый простой услуги (Projected Service Outage или PSO) - документ, определяющий влияние спланированных изменений, деятельности по обслуживанию и планов испытаний на согласованный уровень услуг[1]; • дополнительные ресурсы, которые будут необходимы в случае реализации изменения; • влияние на план обеспечения непрерывности, план распределения мощностей, план обеспечения безопасности и т.п[16]. При оценке важно сфокусироваться на факторах, которые могут навредить бизнесу, препятствовать предоставлению услуг надлежащего качества или негативно влиять на цели и политики организации. Для категорирования рисков многие организации используют таблицы, аналогичные табл. 8.1. Влияние изменения Таблица 8.1. - Таблица для категорирования рисков Категория влияния изменения/рисков Высокое влияние Низкая Высокое влияние Высокая вероятность Категория риска: 2 вероятность Категория риска: 1 Низкое влияние Низкая вероятность Низкое влияние Высокая Категория риска:4 вероятность Категория риска: 3 Вероятность На основании оценки влияния, рисков и выгоды для бизнеса от реализации изменения, менеджмент должен принять решение об утверждении изменения. Если в организации запланировано много изменений, необходимо провести их категорирование. Это позволит установить порядок реализации изменений - наиболее критичные должны выполняться в первую очередь. Категории изменения определяются из двух факторов: • выгода для бизнеса в случае успешной реализации изменения; • издержки и нарушения, которые возникнут, если изменение не будет реализовано. Аккуратное и детальное планирование изменений позволит исключить все неясности в процессе реализации изменения. При планировании рекомендуется ориентироваться на расписание бизнеса, а не IT, дабы не планировать изменения на время, критичное для бизнеса. На этом этапе формируется график изменений и ожидаемый простой услуги (см. выше). Следующим этапом является утверждение изменения уполномоченными лицами. Это может быть один человек или группа людей. Уровень руководства для отдельных изменений определяется исходя из их масштаба, влияния, рисков, стоимости и т.п. Утвержденные RFC поступают на реализацию. При этом процесс Управления изменениями следит за тем, чтобы все изменения осуществлялись согласно расписанию. Как уже отмечалось выше, для каждого изменения должен быть план исправления - действия, которые будут предприняты, если что-то пойдет не так и изменение не получится. При этом в документации к изменению должны быть определены роли и ответственности для тех, кто может инициировать эти планы. Отчет о реализации изменения должен показать, достигло ли изменение поставленных целей. Отчет предоставляется персоналу, ответственному за управление изменениями и всем заинтересованным лицам (в случае значительных изменений). Отчет также должен содержать все проблемы и инциденты, возникшие в процессе реализации изменения. После определенного промежутка времени Управление изменениями должно проводить обзор новой или измененной услуги с целью убедиться, что: • изменение достигло своих целей и принесло ожидаемый эффект; • пользователи, заказчики и другие заинтересованные лица удовлетворены результатами (в том числе определить неудовлетворенность, если она есть); • нет непредвиденных или нежелательных побочных эффектов в функциональности, уровнях услуг, качестве и т.п.; • для внедрения изменения понадобилось столько ресурсов, сколько планировалось; • планы релиза и развертывания были корректно реализованы; • изменение реализовано в заданных рамках времени и затрат; • план по исправлению работает корректно (опционально). В контексте Управления изменениями вводится термин Комитет по изменениям. Комитет по изменениям(Change Advisory Board или CAB) - группа людей, консультирующих менеджера по изменениям при выполнении им оценки соответствия, приоритезации и планирования изменений. Этот комитет обычно формируется из представителей всех заинтересованных сторон - поставщика услуг, бизнеса и третьих сторон, таких как прочие поставщики[1]. CAB принимает решения о принятии изменений, требующих утверждения высокого уровня. При возникновении экстренных ситуаций иногда бывает недостаточно времени для того, чтобы получить одобрение всех членов CAB. Для таких случаев рекомендуется создавать Комитет по срочным изменениям. Комитет по срочным изменениям (Emergency Change Advisory Board или ECAB) группа людей в составе Комитета по изменениям, которые принимают решения по Срочным изменениям с высоким влиянием. Необходимость участия в ECAB может быть выявлена непосредственно при созыве (организации) совещания и определяется исходя из сути Срочного изменения[1]. В рамках Управления изменениями должно быть специализировано, как будет определяться состав CAB и ECAB в той или иной ситуации. Состав CAB должен быть гибким, чтобы обеспечить представление интересов бизнеса в процессе предложения значительных изменений. Состав ECAB должен быть способен принимать необходимые решения в случае непредвиденных обстоятельств. Запросы на изменение могут поступать со всех этапов жизненного цикла услуг, а также от других организаций, в частности, от поставщиков и заказчиков. RFC от Построения стратегии направлены на достижение целей по минимизации рисков и затрат. Например: • изменения в соответствии с законом и требованиями регуляторов; • организационные изменения; • изменения политик и стандартов; • изменения после анализа деятельности (бизнеса, заказчиков, пользователей); • добавление новой услуги на рынок; • обновление Портфеля услуг, портфеля заказчиков или портфеля контрактов; • изменение модели обеспечения; • инновационные технологии. Операционные изменения поступают, как правило, от пользователей. При этом важно понимать различные типы запросов. Это может быть, например, запрос на доступ или смену пароля. Если на этапе Непрерывного улучшения услуг принято решение о том, как может быть улучшена услуга, оно должно быть также оформлено в виде Запроса на изменение, а затем передано Управлению изменениями. Входами процесса Управления изменениями являются: • Политики и стратегии изменений и релизов; • Запросы на изменения; • Предложение изменения; • Планы изменения, внедрения, релиза, развертывания, тестирования, оценки и исправления; • График изменений и Ожидаемый простой услуги(PSO); • активы и конфигурационные единицы; • результаты и отчеты тестирования/оценки. Выходами процесса Управления изменениями являются: • отклоненные RFC; • утвержденные RFC; • изменения услуг и инфраструктуры - результат утвержденных RFC; • новые, измененные или распределенные активы или конфигурационные единицы; • график изменений; • пересмотренный Ожидаемый простой услуги(PSO); • утвержденные планы изменений; • решения и действия по реализации изменений; • документация и записи изменений; • отчеты Управления изменениями. Ключевые показатели производительности для Управления изменениями должны быть связаны с целями бизнеса, в частности, отражать сокращение издержек, увеличение доступности и надежности услуг, которые стали возможными в результате реализованных изменений. Такими показателями могут быть: • количество реализованных изменений, которые смогли удовлетворить согласованные требования заказчиков в качестве/издержках/времени; • выгода изменений - сравнение "ценность сделанных улучшений"+"предотвращенное негативное влияние" и стоимости реализации изменений; • уменьшение количества сбоев услуг, дефектов и дополнительных работ; • уменьшение количества неутвержденных изменений; • уменьшение количества невыполненных запросов на изменение; • уменьшение количества незапланированных изменений и экстренных исправлений; • процент успешных изменений - отношение изменений, признанных успешными, к общему количеству утвержденных запросов на изменение; • уменьшение количества изменений, в рамках которых есть работы по исправлению; • уменьшение количества неудавшихся изменений; • уменьшение количества инцидентов, связанных с изменениями; • и т.п[16]. 8.3. Управление активами и конфигурациями Управление активами и конфигурациями (Service Asset and Configuration Management или SACM) - процесс, ответственный за Управление конфигурациями и Управление активами[1]. Эффективность деятельности любой организации зависит от того, насколько хорошо она управляет своими активами. Именно работа с активами приносит организации прибыль. Управление активами ответственно за управление активами с целью поддержки других процессов Управления услугами. Целью SACM является определение и контроль компонентов услуг и конфигурационных единиц, а также предоставление достоверной информации о состоянии услуг и инфраструктур. Процесс фактически осуществляет инвентаризацию активов и назначение ответственных за их контроль. Управление конфигурациями отвечает за то, чтобы отдельные компоненты услуги, системы или продукта, были должным образом определены, снабжены всем необходимым и контролировались. Процесс также контролирует все изменения компонентов. Он предоставляет модель конфигураций со всеми связями между активами и конфигурациями. Объектом рассмотрения является Конфигурационная единица. Конфигурационная единица (Configuration Item или CI) - любой компонент, который нуждается в управлении для того, чтобы предоставлять услугу. Информация о каждой КЕ регистрируется в форме Записи о КЕ в Системе управления конфигурациями и поддерживается актуальной в течение всего жизненного цикла процессом Управления конфигурациями. КЕ находятся под контролем Управления изменениями. Типичными примерами КЕ являются услуги, оборудование, программное обеспечение, здания, люди и документы, такие как Процессная документация и Соглашения об уровне услуг (SLA)[1]. Для того чтобы управлять конфигурационными единицами, их нужно определить и классифицировать. ITIL рекомендует следующие категории: • СI жизненного цикла - бизнес-кейс, планы сервис-менеджмента, проектная документация, планы релизов, изменений и тестирования. Эти конфигурационные единицы предоставляют полную картину об услугах поставщика и их предоставлении, ожидаемых выгод от использования, затратах и сроках релиза. • CI услуг: o возможности услуг - управление, организация, процессы, знания, люди; o ресурсы услуг - капитал, системы, приложения, информация, данные, инфраструктуры и т.п.; o модель услуг; o пакет услуг; o пакет релизов; o критерии приемки услуг. • CI организации. Некоторая документация определяет характеристики CI, некоторая сама является CI и требует контроля, например, стратегия бизнеса или политика организации; • внутренние СI - материальные и нематериальные активы, которые необходимы для предоставления и управления услугами; • внешние CI - требования заказчиков, соглашения, релизы поставщиков и внешние услуги; • CI интерфейсов - активы, необходимые для предоставления услуг "от начала до конца" в рамках Интерфейса поставщика услуг. Интерфейс поставщика услуг (Service Provider Interface или SPI) - интерфейс между поставщиком услуг и пользователем, заказчиком, бизнес-процессом, или поставщиком. Анализ интерфейсов поставщика услуг помогает координировать сквозное управление услугами[1]. Для управления совокупностью активов Управление активами и конфигурациями ведет Систему управления конфигурациями. Система управления конфигурациями (Configuration Management System или CMS) набор инструментов и баз данных, которые используются для управления данными о конфигурациях поставщиком услуг. CMS также содержит информацию об инцидентах, проблемах, известных ошибках, изменениях и релизах; и может содержать данные о сотрудниках, поставщиках, местоположениях, бизнес-единицах, заказчиках и пользователях. CMS включает в себя инструменты для сбора, хранения, управления, обновления и представления информации обо всех конфигурационных единицах и их взаимоотношениях[1]. Деятельности в рамках Управления активами и конфигурациями показаны на рис. 8.4. увеличить изображение Рис. 8.4. Деятельности в рамках Управления активами и конфигурациям Рассмотрим подробнее деятельности, представленные на рис. 8.4. Управление и планирование Не существует единого шаблона для осуществления SACM. Менеджеры каждой организации устанавливают уровень Управления конфигурациями, приемлемый для конкретного случая и то, как его можно достичь. Это отображается в Плане управления конфигурациями. Пример содержания Плана управления активами и конфигурациями. Контекст и цель. Охват: • применяемые услуги; • среда и инфраструктура: • географическое месторасположение. Требования: • требования стратегии и политик; • требования бизнеса, Управления услугами и контрактов; • совокупность требований к подотчетности и трассируемости; • требования Системы управления конфигурациями. Применяемые политики и стандарты: • политики; • индустриальные стандарты; • внутренние стандарты, относящиеся к Управлению конфигурациями, например, стандарты к оборудованию. Организация Управлением конфигурациями: • роли и ответственности; • комитеты для контроля изменений и конфигураций; • авторизация. Система и инструменты Управления активами и конфигурациями. Процессы и процедуры в рамках Управления активами и конфигурациями, например: • идентификация конфигураций; • управление версиями; • управление интерфейсами; • управление поставщиками; • управление изменениями конфигураций; • релиз и развертывание; • управление сборкой; • управление снабжением; • управление CMS. Ссылка на План реализации Управление и контроль необходимых связей и интерфейсов, в частности, с финансовым управлением активами и поставщиками[16]. Идентификация конфигураций Для идентификации конфигураций важно: • определить, как будут категорироваться активы и конфигурационные единицы; • определить подход к идентификации и наименованию всех активов и конфигурационных единиц; • определить роли и ответственности для владельцев конфигурационных единиц отдельных типов в рамках этапов жизненного цикла, например, владелец услуги в процессе релиза. Деятельность в рамках идентификации конфигураций включает в себя: • определение и документирование критериев выбора конфигурационных единиц и составляющих их компонентов; • выбор конфигурационных единиц и их компонентов на основе установленных критериев; • назначение уникальных идентификаторов для выбранных конфигурационных единиц; • определение атрибутов для каждой конфигурационной единицы; • определение для каждой конфигурационной единицы момента, когда она поступает в Управление конфигурациями; • определение владельца, ответственного за каждую конфигурационную единицу. Модель конфигураций должна включать в себя связи и позицию каждой конфигурационной единицы. Важной частью Управления конфигурацией является определение уровня контроля для каждой конфигурационной единицы. Для этого применяется иерархический подход, так как каждая CI может являться частью другой CI или группы CI. Например, база данных может использоваться многими приложениями. Конфигурационные единицы нижних уровней не подвержены детальному контролю и аудиту. Например, клавиатуры, используемые в организации, могут послужить примером CI нижнего уровня. Важно отметить, что в зависимости от конкретной организации, критерии выбора CI нижнего уровня отличаются. Например, в здании ООН работает множество людей, говорящих на разных языках. Для их удобства используются разные клавиатуры - с английской, русской, итальянской и другими раскладками. Следовательно, для ООН информация о клавиатурах является относительно критичной и клавиатура как CI не находится на нижнем уровне иерархии. Всем конфигурационным единицам необходимо назначить имена, состоящие из идентификатора и версии. Имена должны быть уникальными. Помимо этого все физическое оборудование должно иметь бирки, по которым их можно будет легко идентифицировать. Атрибуты конфигурационных единиц описывают характеристики, значимые в рамках SACM. В базе данных должны содержаться атрибуты каждой конфигурационной единицы. ITIL выделяет следующие стандартные атрибуты: • уникальный идентификатор; • тип CI; • имя/описание; • версия; • расположение; • дата поставки; • детали лицензии ( в частности, дата ее истечения); • владелец/куратор; • статус; • поставщик/источник; • документация; • данные истории, например, аудиторские отчеты; • тип связей; • соответствующий SLA[16]. Чаще всего характеристики CI содержатся в документации к ней. Связи конфигурационных единиц отражают то, как они взаимодействуют друг с другом в процессе предоставления услуг. Информация о связях хранится в CMS. Основные связи между CI: • CI является частью другой CI. Например, сервер является частью инфраструктуры сайта. Это отношение "родитель-ребенок"; • CI соединен с другим CI. Например, персональный компьютер соединен с локальной сетью; • CI использует другой CI. Например, программа использует модуль другой программы; • CI установлена на другую CI, например, Microsoft Excel на персональный компьютер. CI может иметь множество связей. Например, быть частью другой CI и одновременно использоваться другими CI. Контроль конфигураций Контроль конфигураций предоставляет механизмы контроля для конфигураций. CI не может быть перемещена, изменена, удалена без соответствующего контроля. Процедуры и политики контроля включают в себя: • лицензионный контроль - проверяет количество людей, которые используют лицензионный продукт, следит за тем, чтобы в организации не использовались нелицензионные продукты, следит за сроками истечения лицензий и т.п.; • управление изменениями; • контроль версий активов, программного и аппаратного обеспечения, релизов, сборок и т.п.; • контроль активов - возможности, место хранения, CMS; • контроль сборки с использованием документации от CMS; • поддержка и миграция электронных данных и информации; • формирование базы активов и конфигурационных единиц перед релизом; • контроль развертывания; • инсталляция; • управление целостностью Библиотеки эталонного ПО. Библиотека эталонного ПО (Definitive Media Library (DML) - одно или несколько защищенных хранилищ, в которых находятся определенные и авторизованные версии всех конфигурационных единиц, относящиеся к программному обеспечению. DML также может содержать CI, ассоциированные с ПО, такие как лицензии и документация. DML является логически единым хранилищем, даже если физически места хранения распределены. Все программное обеспечение в DML находится под контролем Управления изменениями и Управления релизами, должно быть зарегистрировано в Системе управления конфигурациями. В релизе может быть использовано только программное обеспечение из DML[1]. Механизмы контроля должны быть спроектированы и встроены в новую или измененную услугу на ранних этапах ее развертывания. Учет статусов Каждая CI имеет ряд дискретных статусов в рамках своего жизненного цикла. Значимость каждого статуса определяется использованием CI в его рамках. Выделяют следующие статусы: • разработка или проектирование - CI находится на этапе проектирования и пока ее нельзя использовать; • утверждена - CI утверждена, и могут проводиться дальнейшие работы; • отозвана - CI больше не используется. Необходимо четко определить, как CI будет переходить из одного статуса в другой. Пример жизненного цикла приложения на рис. 8.5. увеличить изображение Рис. 8.5. Пример жизненного цикла конфигурационной единицы Учет статусов обеспечивает корректность и актуальность записей о конфигурационных единицах, активах и их состояниях. Стандартные деятельности в рамках Учета состояний: • управление записями о конфигурациях в процессе жизненного цикла; • управление записью, восстановлением и объединением статусов с целью обеспечения корректности, безопасности, своевременности и целостности; • обеспечение доступности информации о статусах в рамках Управления конфигурациями; • запись всех изменений в CI. Запись о конфигурации создается в процессе идентификации и контроля CI, рассмотренных нами выше. Она обеспечивает прозрачность и трассируемость CI для всех процессов. Стандартная запись содержит следующее: • информация о конфигурации - идентификационный номер, версия, статус, история изменений и т.п.); • конфигурация услуги или продукта - статус проектирования или сборки; • статус релиза обновления для конфигурации; • изменения, которые осуществлены или осуществляются; • сбор результатов тестирования качества. Проверки Включает в себя набор следующих проверок: • соответствие документации и актуального состояния CI; • физическое наличие CI в организации, функциональные характеристики; • документации для релиза до его осуществления. Только авторизованные и корректные CI должны использоваться для поддержки услуг. Если в рамках проверок выявлены нарушения, они должны быть немедленно устранены, а результаты проверок отображены в соответствующих отчетах. Как и любой другой процесс, SACM имеет свои ключевые показатели производительности. Применяются следующие метрики: • процентное улучшение в управлении расписаниями в рамках жизненного цикла активов; • ускоренная идентификация активов, вызвавших сбои в работе услуг; • уменьшение влияния инцидентов и ошибок на CI; • процент лицензий, которые используются, к общему количеству купленных ( в идеале 100%); • увеличение качества информации о CI в CSM; • уменьшение использования нелицензионного ПО; • и т.п. Информацию, формируемую в рамках SACM, используют все процессы в рамках жизненного цикла услуг. Лекция 9: Управление релизами и развертыванием в рамках Внедрения услуг Аннотация: В лекции рассматривается процесс Управления релизами и развертыванием в рамках этапа Внедрения услуг: цели, входы и выходы процесса, основные деятельности в его рамках. Ключевые слова: единица, компьютер, аппаратное обеспечение, приложение, pass, fail, деятельность, развертывание, ITIL, контрольная точка, информация, CMS, релиз, контроль, оборотный капитал Управление релизами и развертыванием отвечает за предоставление и тестирование возможностей для предоставления услуг, определенных на этапе Проектирования. Основные цели Управления релизами и развертыванием: 1. формирование и согласование планов релизов и развертывания с заказчиками и инвесторами; 2. гарантия того, что каждый пакет для релиза состоит из набора связанных и совместимых компонентов; 3. осуществление управления релизом и его компонентами в рамках процессов Внедрения; 4. гарантия того, что все пакеты для релизов могут быть протестированы, отслежены, проверены, установлены или устранены (при необходимости); 5. гарантия того, что все изменения управляются в рамках деятельностей по управлению релизами и развертыванием; 6. ведение отчетов и управление рисками, проблемами, расхождениями, связанными с новой или измененной услугой. Осуществление корректирующих действий при необходимости; 7. обеспечение доступа к информации для заказчиков и инвесторов, чтобы они могли эффективно использовать новую или измененную услугу; 8. обеспечение доступа к информации для операционного персонала, чтобы он мог предоставлять, поддерживать и управлять услугой. Управление релизами и развертыванием отвечает за выпуск релизов и их эффективное использование заказчиками. Единица релиза (Release Unit) - компоненты услуги, которые обычно компонуются вместе и выпускаются в рамках одного релиза. Единица релиза обычно включает в себя компоненты, необходимые для выполнения какой-либо полезной функции. Например, Единицей релиза может быть настольный компьютер, включающий в себя программное, аппаратное обеспечение, лицензии, документацию и т.п. Другим примером Единицы релиза может служить целое приложение для расчета зарплаты, включая процедуры операционного управления IT и тренинги пользователей[1]. Важно определить подходящий уровень Единицы релиза для каждого актива и компонента. Необходимо учитывать следующие факторы: • простота и количество изменений, необходимых для релиза и развертывания; • количество ресурсов и времени, необходимое для сборки, тестирования и развертывания; • сложность взаимосвязей между единицей и остальными услугами и компонентами; • хранение, доступное в рамках сборки, тестирования, распространения и эксплуатации[16]. Подход преобразования новой или измененной услуги определяется в рамках этапа Проектирования. Существует две опции внедрения: 1. "большой взрыв" - новая или измененная услуга развертывается сразу для всех пользователей в рамках одной операции; 2. пофазовый подход - услуга развертывается поэтапно. Сначала одной части пользователей, затем остальным. На рис. 9.1 представлено применение двух подходов. увеличить изображение Рис. 9.1. Два подхода к развертыванию услуг 1. Релиз 1 - начальная установка на три рабочие станции (1-3). Две другие станции добавляются в тот же период времени (4-5); 2. Релиз 2 - использование подхода "большой взрыв" для развертывания. Релиз устанавливается сразу на пять рабочих станций (1-5). На другом шаге на две дополнительные станции (6-7); 3. Релиз 3 - пофазовый подход для развертывания. Сначала обновляется только три рабочие станции (1-3), затем оставшиеся четыре (4-7). Еще одна станция добавляется на следующем этапе (8). Пофазовый подход имеет следующие вариации: 1. порции услуги предоставляются для использования по фазам, но все пользователи будут подключены к ней одновременно; 2. каждый релиз развертывается постепенно в зависимости от количества конечных пользователей; 3. разные элементы услуги развертываются в рамках разных фаз; 4. комбинированный подход, применяющий все описанные выше. Пофазовый подход возможен только в том случае, если старая и обновленная услуги совместимы и могут работать одновременно. Рассмотрим последовательность действий в рамках Управления релизами и развертыванием. Для развертывания релиза необходимо разработать различные планы, в частности, Планы релизов и развертывания. Они должны определять: • охват и контекст релиза; • оценку рисков для релиза; • организации и отдельные лица, которых затронет релиз; • инвесторов, которые утвердили запрос на изменение; • команду, ответственную за релиз; • подход к взаимодействию с инвесторами и группами развертывания, который определяет: o стратегию предоставления и развертывания; o ресурсы для релиза и развертывания; o количество изменений, которые могут быть осуществлены. В рамках Внедрения должны быть определены критерии, которые позволят установить успешность выполнения каждой стадии релиза и развертывания. Результат выполнения либо принимается pass, либо отклоняется - fail. Отсюда критерии называются прием/отклонение (pass/fail) критерии. Пример, когда результат принимается: • Все тесты завершены успешно; отчет по оценке и RFC для сборки и тестирования подписаны. Примеры, когда результаты отклоняются: • недостаток ресурсов для перехода на следующую стадию. Например, тестирование показало недостаточность финансовых средств для предоставления спроектированной услуги на стадии эксплуатации; • этап Эксплуатации услуг не может предоставить отдельные атрибуты услуг; • этап Проектирования услуг разработал проект, не соответствующий установленным стандартам, технологиям, требованиям регуляторов и т.п.: • услуга не может быть предоставлена в соответствии с ограничениями, наложенными на этапе Проектирования; • не выполняются критерии приемки услуги; • необходимые документы не подписаны; • SKMS и CSM не обновлены и содержат неактуальную информацию; • количество инцидентов, проблем и рисков выше, чем предполагалось изначально. Перед передачей услуги в промышленную эксплуатацию, необходимо совершить ряд действий по сборке и тестированию различных сред. Деятельность в рамках планирования сборки и тестирования заключается в: • формирование планов сборки исходя из проектной документации, спецификаций, требований к конфигурации оборудования; • формирование команд сопровождения, логистики и сборки, необходимых для поддержки сред; • тестирование сборки; • составление расписаний для тестирования и сборки; • назначение ролей, распределение ресурсов и ответственности для ключевых деятельностей; • согласование критериев приемки сборки. Среды, необходимые для релиза: • среда сборки - используется для сбора и комплектования пакета релиза; • единичная среда тестирования - используется для проверки функциональности, производительности, восстанавливаемости и полезности отдельных компонентов услуги; • комплект сред тестирования - используется для проверки функциональности, производительности, восстанавливаемости и полезности комплекта компонентов услуги; • среда интеграции - используется для сборки и интеграции компонентов услуги; • среда тестирования услуги - используется для тестирования всех аспектов объединенной архитектуры услуги; • среда тестирования релиза - используется для установки, сборки и тестирования пакета релиза в контролируемой среде; обычно совмещена со средой тестирования услуги. • среда тестирования готовности к эксплуатации - для тестирования возможностей услуги и ее компонентов перед передачей в промышленную эксплуатацию; • среда, симулирующая бизнес-среду; • среда, симулирующая Управление услугами; • среда для обучения; • среда для пилотирования; • среда для резервного копирования и восстановления. Для тестирования услуги на маленькой части пользователей используются пилоты. Пилот (Pilot) ограниченное развертываниеуслуги, релиза или процесса в среде промышленной эксплуатации. Пилот используется для сокращения рисков и получения обратной связи, а также приемки от пользователей[1]. При этом важно определить оптимальный охват пилота. Если он будет слишком маленьким, будет некорректно отображена функциональность услуги и не выявятся многие ошибки. Для пилотирования также должны формироваться планы. Планирование сборки пакета релизов содержит следующие процедуры: • проверка критериев входа/выхода; • взаимодействие с инвесторами: o управление контрактами и их деталями; o доведение до инвесторов информации о предлагаемых изменениях, выгоде, которую они могут принести и сопутствующих затратах и рисках • обучение персонала и передача знаний; • установление услуг и активов в виде имеющихся контрактов; • согласование графиков; • разработка механизмов и инструментов для: o сборки, тиражирования, продвижения, распространения, контроля, инсталляции и активации релизов; o управления лицензиями и авторскими правами. • настройка систем и обучение пользователей для работы с новой или измененной услугой; • разработка возможностей и ресурсов для сервис-менеджмента; • оценка готовности целевой группы к использованию релиза; • определение и согласование критериев для выхода. В рамках составления планов развертывания необходимо ответить на следующие вопросы: • для кого предназначено развертывание? • кто будет пользователями? • есть ли какие-то особенности месторасположения?(например, какие-то дополнительные выходные в зависимости от региона) • где пользователи? (например, есть ли удаленные пользователи или все пользователи будут работать в одном месте) • кто еще должен быть подготовлен к релизу? (например, нужно ли дополнительное обучение персонала сервис-деска) • когда необходимо завершить развертывание? • почему необходимо развертывание? (например, чтобы исправить какую-то проблему или увеличить функциональность) • какие факторы успеха и критерии выхода? (как узнать, что развертывание прошло успешно и может быть завершено) • каковы текущие возможности поставщика услуг? Далее разрабатываются Планы снабжения и предоставления. Они определяют следующее: • как и когда релиз и его компоненты будут предоставляться? • какие имеются команды сопровождения, и что будет в случае задержки? • как отследить прогресс в предоставлении и необходимость его завершения? • есть ли возможность защищенного хранения, если потребуется? Прежде чем добавлять какие-то действия в планы развертывания, необходимо осуществить финансовое планирование. Оно рассматривает вопросы выделения средств для обеспечения деятельностей, покупки необходимого оборудования и лицензий, имеющиеся контракты и обязательства. После того, как детальные планы для каждой деятельности в рамках Управления релизами и развертыванием составлены, наступает этап подготовки к сборке, тестированию и развертыванию. На этом этапе происходит оценка рисков, возможных проблем и несоответствий в проектной документации. Оценка проверяет, принесет ли изменение желаемые результаты. Формируется отчет, в котором содержатся рекомендации об утверждении изменения или его отклонении. Если изменение утверждено, наступает этап сборки и тестирования. Ключевые аспекты, которыми необходимо управлять в рамках этого этапа: • использование сред сборки и тестирования; • стандартизация и интеграция; • управление конфигурациями: • в ходе деятельностей по сборке и тестированию - контроль версий, управление базовым состоянием, контроль входов и выходов этапа сборки и тестирования; • ведение отчетности, которая позволит осуществить сборку снова при возникновении необходимости; • управление наглядностью тестирования - формирование отчетов по тестированию; • контроль доступа к физическим компонентам и технологиям; • проверка выполнения требований безопасности; • проверка деятельностей - все необходимые условия выполнены; • управление вопросами среды - кондиционирование, электропитание, физическое место, пожарная сигнализация и т.п. • проверка готовности релиза к передаче на следующую стадию; • передача релиза на следующую стадию. В ITIL вводится понятие "базовое состояние". Базовое состояние (Baseline) - зафиксированное состояние, используемое как ориентир (контрольная точка)[1]. Трактовка зависит от контекста. В контексте Внедрения базовое состояние может быть использовано для возврата инфраструктуры к исходной конфигурации в случае, если внедрение релиза оказалось неудачным. Информация о базовых состояниях конфигураций хранится в CMS. Для сборки релиза необходимо объединить множество компонентов, активов и продуктов от внешних и внутренних поставщиков. В этом большую роль играет документация - соглашения, контракты, лицензии и т.п. Деятельность по приобретению компонентов включает в себя: • взаимодействие с процессами снабжения для приобретения компонентов; • сбор: o информации о новых и обновленных активах и конфигурационных единицах от SACM; o квитанций и чеков; o документации предоставления, релиза и изменения от поставщика. • проверка, мониторинг и ведение отчетности о качестве поступающих конфигурационных единиц и компонентов услуг; • обеспечение того, что наличие лицензии можно будет доказать при возникновении необходимости; • ответные действия в случае, если качество, полученное на практике, отличается от ожидаемого, и оценка влияния снижения качества на внедрение в целом; • обновление статусов конфигурационных единиц в SACM. После того, как все необходимое куплено, документация готова, можно приступить к сборке пакета релизов. При сборке релизов важно понимать, что продукт поступит скоро в промышленное производство, следовательно, использованные в рамках сборки процедуры должны быть повторимы в случае необходимости. Ключевые этапы деятельности сборки пакета релизов: • комплектование и интеграция компонентов релиза; • создание документации для сборки и релиза o планы сборки, тестирования и инсталляции; o детальное описание механизмов мониторинга и проверки качества релиза; o детальное описание ответных действий в случае возникновения проблем; o автоматические и ручные процедуры, необходимые для развертывания услуги в среде промышленной эксплуатации; o процедуры по возвращению в исходное состояние в случае неудавшегося релиза; o процедуры контроля лицензий. • инсталляция и проверка пакета релиза; • отправка уведомлений всем заинтересованным участникам о том, что пакет релиза готов для инсталляции и использования. Если тестирование пакета релизов прошло успешно, релиз и его составляющие попадают под контроль Управления конфигурациями. С этого момента все изменения в пакете релизов осуществляются через Управление изменениями. Критерии тестирования должны отражать условия, в которых услуга будет использоваться и предоставлять выгоду заказчикам. Тестирование релиза проверяет, что компоненты релиза могут корректно интегрироваться, а сам релиз можно инсталлировать в целевую среду. Тестирование операционной готовности проверяет, что услуга и поддерживающие ее инфраструктуры могут быть переданы в производство. Оно также предоставляет определенный уровень уверенности в том, что новая или измененная услуга будет соответствовать установленным требованиям. В рамках тестирования операционной готовности проводятся следующие тесты: • тестирование готовности к развертыванию - проверяет то, что процессы, процедуры и системы развертывания могут развертывать, устанавливать, назначать и списывать пакет релизов и соответствующую ему услугу в среде производства/развертывания; • тестирование Управление услугами - проверка того, что производительность услуги может быть измерена и проконтролирована в процессе промышленной эксплуатации; • тестирование группы эксплуатации - проверяет, что сервисные подразделения смогут управлять услугой в процессе промышленной эксплуатации; • тестирование уровня услуг - проверка соответствия новой или измененной услуги требованиям уровня услуг; • тестирование пользователей - проверка того, что пользователи имеют доступ к новой или измененной услуге и могут ее использовать; • тестирование интерфейса поставщика услуг - проверка того, что интерфейсы, поддерживающие услугу, функционируют; • тестирование развертывания - проверка того, что услуга корректно развернута для каждой целевой группы или среды. После проведения указанных выше тестов наступает заключительный этап тестирования "репетиция услуги". Это метод тестирования, в котором создаются условия, максимально приближенные к условиям реальной эксплуатации. Он должен выявить ошибки и неработающие процессы, прежде чем они повлияют на бизнес в процессе промышленной эксплуатации. Проводится перед непосредственным развертыванием услуги. Как вариант может осуществляться в виде пилота - то есть на маленькой группе реальных пользователей услуги. После успешного тестирования или пилотирования можно приступить к развертыванию услуги. На начальном этапе составляются детальные планы развертывания, и производится оценка рисков. Планы должны быть утверждены, а Запросы на изменения авторизованы процессом Управления изменениями. Только после этого услуга готова к развертыванию. В рамках развертывания могут выполняться следующие действия: 1. перенос финансовых активов: o любые изменения в финансовых соглашениях; o покупка или перенос ежегодной поддержки; o управление затратами, в том числе на системы управления услугой; o новые цены на лицензии и обновления; o годовые контракты на восстановление в случае сбоя с третьими сторонами; o предоставление или перенос оборотного капитала; o перенос прав на интеллектуальную собственность. 2. Перенос/переход бизнеса и организации 3. окончательное оформление организационной структуры, ролей и ответственностей; 4. установление связей между изменениями организации, ролей и ответственностей; 5. убедиться в том, что люди могут приспособиться к новым практикам; 6. убедиться в том, что люди понимают планы и процедуры обеспечения непрерывности. Сюда также входит найм квалифицированного персонала, способного реализовать развертывание. • развертывание процессов и материалов; • развертывание возможностей Управления услугами - новые процессы, инструменты и системы для персонала, ответственного за управление услугами. • перенос услуги: o перед переносом пересматриваются риски, проблемы услуги и значения ее производительности; o настройка аудита для услуги и конфигураций; o внесение в Каталог услуг информации о новой или измененной услуге; o уведомление инвесторов об изменении. • развертывание услуги - развертывание релиза, в том числе действия по распространению и установке услуги, поддерживающих услуг, приложений, инфраструктуры и функциональных возможностей. В этот этап входят следующие деятельности: o распространение и развертывание услуги и ее компонентов в заданных границах времени; o сборка, установка и настройка услуги и ее компонентов на работу с новой или преобразованной информацией; o тестирование системы и услуг в рамках инсталляции, формирование отчетов об инсталляции и тестировании; o фиксация всех проблем, сбоев, ошибок, инцидентов и расхождений с планами; o корректирование всех расхождений, которые не выходят за рамки проектных ограничений. • Отзыв услуги - действия, предпринятые для того, чтобы релиз можно было отозвать в случае возникновения необходимости: o удаление развернутых копий программного обеспечения и данных с аппаратного обеспечения; o идентификация лицензий и других активов, которые могут быть отозваны; o расположение оборудования в соответствии с политиками и процедурами; o перемещение отозванных активов в защищенное хранилище при необходимости[16]. Записи о действиях по отзыву, восстановлению и расположению должны управляться и использоваться для обновления другой информации, например, об имеющихся в организации лицензиях. • удаление избыточных активов. Если услуга отозвана, необходимо пересмотреть использование активов. Активы отозванной услуги могут быть использованы для других услуг либо извлечены из обращения, что приведет к снижению издержек. • верификация развертывания. После того, как деятельности в рамках развертывания завершены, необходимо убедиться, что пользователи, группа эксплуатации и инвесторы готовы к использованию услуги. Это включает в себя выполнение следующих действий: • o проверка того, что услуги, активы и ресурсы "на своих местах"; o проверка того, что обновление документации и информации завершено; o материалы для обучения и координации готовы для предоставления инвесторам, пользователям и группе эксплуатации; o проверка того, что роли и ответственности распределены; o персонал и другие ресурсы готовы для управления и использования услуги и ее компонентов в нормальных и экстренных условиях; o участники имеют доступ к информации, необходимой для управления, поддержки и использования услуги; o настроены механизмы измерения производительности услуги и поддерживающих ее ресурсов. поддержка в начале эксплуатации (Early Life Support или ELP) - поддержка, предоставляемая в отношении новой или измененной услуги в течение некоторого времени непосредственно после того, как услуга была введена в эксплуатацию. Во время поддержки в начале эксплуатации поставщик услуг может пересматривать ключевые показатели производительности, уровни услуги и наблюдаемые пороговые значения, а также задействовать дополнительные ресурсы для Управления инцидентами и Управления проблемами[1]. Пример деятельностей в рамках Поддержки в начале эксплуатации показан на рис. 9.2. увеличить изображение Рис. 9.2. Пример деятельностей в рамках Поддержки в начале эксплуатации В процессе ELP группа развертывания реализует улучшения и решает возникающие проблемы, то есть стабилизирует использование услуги. Также происходит обновление базы данных дополнительными данными диагностики, известными ошибками, наиболее часто задаваемыми вопросами и т.п. • обзор и завершение развертывания Обзор развертывания включает в себя следующие действия: o организация опросов и исследований удовлетворенности пользователей, инвесторов и заказчиков новой или измененной услугой; o выявить недостигнутые критерии качества; o проверить завершенность всех необходимых действий, исправлений и изменений; o пересмотреть незавершенные изменения и убедиться в том, что для них выделены финансовые средства и назначены ответственные исполнители; o пересмотреть целевые показатели производительности и успешности; o убедиться, что все проблемы, связанные с ресурсами, возможностями, мощностями и производительностью, решены до завершения развертывания; o проверить то, что все проблемы, известные ошибки и обходные решения согласованы с инвесторами, заказчиками и пользователями. Обходное решение (Workaround) уменьшение или устранение влияния инцидента или проблемы, для которых в текущий момент недоступно полное разрешение. Например, перезапуск отказавшей конфигурационной единицы. Обходные решения для проблем документируются в записях об известных ошибках. Обходные пути для инцидентов, которые не привязаны к записям о проблемах, документируются в записях об инцидентах[1]. o пересмотреть все риски и выявить те, которые влияют на эксплуатацию и поддержку услуги; o проверить то, что избыточные активы извлечены из обращения; o проверить готовность услуги к передаче от ELP в промышленную эксплуатацию. Обзоры, проводимые после завершения развертывания, контролируются процессом Управления изменениями. • обзор и завершение внедрения Перед тем, как завершить Внедрение полностью, необходимо предоставить формальный обзор Внедрения, включающий в себя: o проверку того, что все деятельности в рамках Внедрения завершены, то есть информация и документация собраны, обновлены, защищены; o проверку того, что применяются правильные и точные метрики. Обзор аккумулирует выходы всех процессов, процедур и деятельностей в рамках Внедрения. Успешное проведение оценки гарантирует то, что услуга передана на этап Эксплуатации. Входами процесса Управления релизами и развертыванием являются: • авторизованные Запросы на изменения; • Проектная документация; • пакет уровней услуг; • План обеспечения непрерывности бизнеса и IT; • Планы и стандарты сервис-менеджмента; • технологические стандарты и каталоги снабжения; • приобретенные активы и компоненты с их документацией; • модели и планы сборки; • требования и спецификации сред для сборки, тестирования, пилотирования, развертывания, обучения и восстановления; • политика и проект релизов от этапа Проектирования; • модели релизов и развертывания; • критерии входа и выхода для каждой стадии развертывания и релиза. Выходами процесса Управления релизами и развертыванием являются: • План релиза и развертывания; • завершенные Запросы на изменения для деятельностей в рамках релиза и развертывания; • оповещение об услуге; • обновленный Каталог услуг с информацией о новой или измененной услуге; • новые протестированные возможности услуги и среды; • новая или измененная документация сервис-менеджмента; • пакет услуг, учитывающий требования бизнеса/заказчиков к услугам; • Пакет уровней услуг (SLP); • SLA, OLA и другие контракты; • модель услуг, описывающая структуру и динамику управления и использования услуг; • отчеты о новых или измененных услугах; • протестированные планы непрерывности; • полный и актуальный перечень конфигурационных единиц; • план мощностей соответствующий планам бизнеса; • подготовленный пакет релизов - для развертываний в будущем; • отчет о внедрении. Ключевые показатели производительности Управления релизами и развертыванием можно разделить на два класса: 1. Заказчики и бизнес: o уменьшение отклонения значений производительности услуг от требуемых заказчиками и бизнесом; o уменьшение количества инцидентов, связанных с услугами; o увеличение удовлетворенности пользователей и заказчиков предоставленными услугами; o уменьшение неудовлетворенности пользователей и заказчиков. 2. Поставщики услуг: o уменьшение необходимых ресурсов и затрат для диагностирования и исправления инцидентов и проблем в рамках развертывания и производства; o увеличение использования стандартизированного подхода к Внедрению, в том числе процессов, документации и стандартов; уменьшение несовпадений между информацией, предоставляемой проверками конфигураций, и реальной ситуацией. Лекция 10: o Подтверждение, тестирование и оценка услуг на этапе Внедрения. Управление знаниями Аннотация: Процессы и деятельности в рамках этапа Внедрения услуг: цель, входы и выходы, основные деятельности и ключевые показатели эффективности. В лекции рассматриваются следующие процессы: Подтверждение и тестирование услуг, Оценка и Управление знаниями. Ключевые слова: деятельность, SLP, очередь, дизайн, корректность, сценарий, тестирование безопасности, SDP, производительность, вероятность, ущерб, место, анализ, информация, knowled ge, e-mail, работ, опыт, принятия решений, инструментарий, базы данных, CMS 10.1. Подтверждение и тестирование услуг Подтверждение(Validation) - деятельность, которая гарантирует, что новая или измененная услуга, процесс, план или другой результат отвечает нуждам бизнеса. Подтверждение гарантирует, что требования бизнеса удовлетворены, даже если они могли измениться по отношению к исходному результату проектирования. Подтверждение и тестирование услуг (Service Validation and Testing) - процесс, ответственный за подтверждение и тестирование новой или измененной услуги. Подтверждение и тестирование услуг удостоверяет, что услуга соответствует ее спецификации проектирования и будет отвечать потребностям бизнеса[1]. Если не протестировать услуги корректно, при их передаче в промышленную эксплуатацию вырастет количество: • инцидентов, связанных со сбоями элементов услуг и несовпадениями между прогнозами и практикой; • количество звонков и обращений в сервис-деск, вызванных тем, что услуги не функционируют должным образом; • проблем и ошибок, которые труднее диагностировать в процессе эксплуатации; • издержек, так как ошибки сложнее и дороже исправлять в процессе эксплуатации, чем в процессе тестирования; • услуг, которые не могут использоваться эффективно пользователями и предоставлять им желаемую ценность. Основные цели процесса Подтверждения и тестирования услуг: • планирование и последующая реализация процессов тестирования и подтверждения, которые представят объективные доказательства того, что услуги предоставляют заявленную ценность заказчикам, пользователям и инвесторам; • оценка качества релиза и его компонентов; • идентификация, оценка и улаживание проблем, ошибок и рисков в процессе Внедрения. Таким образом, Подтверждение и тестирование услуг позволяет удостовериться, что услуга сможет предоставлять ценность заказчикам и их бизнесу. Услуга определяется пакетом услуг, который может состоять из нескольких пакетов уровней услуг (SLP) и компонентов, которые в свою очередь также могут быть услугами, например, поддерживающими. SLP определяет уровень полезности и качества, которые должны предоставлять услуги, и является основным входом процесса Подтверждения и тестирования услуг. Дизайн(проект) услуги зависит от того, где и как она будет использоваться. Атрибуты услуги характеризуют ее форму и функциональность в контексте перспективы использования. Таким образом, SLP определяет совокупность требований к услугам, а также набор ограничений для их использования. Процесс Подтверждения и тестирования услуг должен определить возможности устранения ограничений, определенных на этапе Проектирования, и проверить их корректность. Прежде чем начинать тестирование, необходимо сформировать стратегию тестирования. Стратегия тестирования определяет подход к организации тестирования и обработке его результатов. Она может применяться ко всей организации, набору услуг или отдельной услуге. Каждая стратегия должна согласовываться с инвесторами, так как они выделяют деньги на ее реализацию. Содержание стратегии тестирования: • цели и задачи тестирования; • контекст; • стандарты, требования законов и регуляторов; • контракты и соглашения; • охват и организация: o команды поставщика услуг; o организация тестирования; o третьи стороны, стратегические партнеры, поставщики; o бизнес-единицы и их месторасположение; o пользователи и заказчики. • процесс тестирования: o управление и контроль тестированием - запись, мониторинг прогресса, ведение отчетности; o планирование и оценка тестирования; o действия в рамках тестирования - планирование, реализация и документирование тестов и их результатов. • метрики тестирования и улучшения • идентификация объектов тестирования: o пакет услуг; o пакет уровня услуг; o модель услуг, отображающая структуру и динамику развития услуг; • план эксплуатации услуг; • планы сервис-менеджмента: o критические элементы, на которых необходимо сконцентрировать тестирование; o месторасположение бизнес-единиц, на которых будет осуществляться тестирование. • интерфейсы поставщика услуг; • подход: o выбранная модель тестирования; o уровни тестирования; o подходы к тестированию; o степень независимости реализации, оценки и анализа тестирования; o повторное использование - опыт, практика, знания и результаты тестирований в прошлом; o распределение по времени; o разработка и повторное использование проектов, инструментов, сценариев и данных для тестирования; o контроль изменений и исправление ошибок; o • система измерения. критерии: o приема/отклонения; o входа и выхода для каждой стадии тестирования; o остановки или повторного запуска тестирования. • требования к людям: o роли и ответственности; o составление расписания тренингов для персонала; o требования к степени вовлеченности заинтересованных лиц - поставщиков услуг, поставщиков, заказчиков, пользователей. • требования к среде: o среды тестирования, которые будут использованы, их расположение, организация и техническое оснащение; o требования к каждой среде тестирования; o планирование и ввод в эксплуатацию сред тестирования. • результаты: o обязательная и опциональная документация; o планы тестирования; o спецификации тестирования - процедуры, проект, обоснование тестирования; o результаты тестирования и отчеты; o проверка отчетов; o суммарные отчеты по тестированию. Модель тестирования включает в себя план тестирования, то, что должно быть протестировано и сценарий тестирования каждого элемента. Сценарии тестирования определяют условия тестирования, цикл тестирования и результаты, которые должны быть получены. Таблица 10.1 . - Примеры моделей тестирования Модель тестирования Результат/цель тестирования Условия, на которых основано тестирование Тестирование контрактов Заказчик может использовать услугу с целью получения Требования ценности контрактов Модель тестирования требований к услугам Поставщик услуг может предоставлять услугу с характеристиками, которые требует заказчик Модель тестирования уровня услуг Поставщик услуг предоставляет услугу с заданным Требования уровня уровнем услуг, то есть тестирование времени ответа и услуг, SLA, OLA исправления ошибок, доступности, вспомогательных услуг Требования к услугам и Критерии приемки услуг Модель Поставщик услуг способен предоставлять, Модель услуг тестирования услуги сопровождать и управлять новой или измененной услугой с использованием модели услуг, включающей в себя модель ресурсов, модель затрат, модель прогресса, модель мощностей и производительности и т.п. Модель тестирования инсталляции Команда развертывания, инструменты и процедуры Проект и план могут инсталлировать пакет релизов в целевую среду в релизов и заданных временных рамках развертывания Модель тестирования верификации развертывания Развертывание завершено успешно, все услуги и конфигурации "на своих местах" и соответствуют критериям качества Тесты и проверки текущего состояния активов и конфигураций Существует множество подходов к тестированию. Они могут комбинироваться или использоваться по отдельности в зависимости от того, что конкретно тестируется. Например: • обзор документации; • моделирование и измерение - подходит для тестирования модели услуг и плана эксплуатации; • подход, основанный на рисках - концентрируется на областях повышенного риска, например, критичных для бизнеса услугах; • подход, основанный на проверке соответствия стандартам; • подход, основанный на опыте - использование экспертов в конкретной области для руководства тестированием; • симуляция; • тестирование по сценариям; • разыгрывание ролей; • макетирование; • тестирование в лабораторных условиях; • регрессивное тестирование; • пилотирование в отдельном помещении; • пилотирование в среде промышленной эксплуатации[16]. Чтобы оптимизировать использование ресурсов в рамках тестирования, необходимо расставить приоритеты тестирования в зависимости от значимости услуги для бизнеса, влияния услуги и рисков, ассоциированных с ней. Существуют разные типы тестирования. Рассмотрим некоторые из них: • тестирование структуры услуги и требований к ней. Проверка атрибутов услуг в контексте контрактов, компонентов услуг и поддерживающих ее активов на совместимость; • тестирование гарантии. Как уже говорилось в предыдущих лекциях, пользователи видят и измеряют ценность услуги в двух составляющих - гарантии и полезности. При этом для каждой услуги определяются четкие показатели гарантии. Эта четкость позволяет провести тестирование гарантии или того, что услуга подходит для использования. В рамках тестирования гарантии могут проводиться: o тестирование доступности; o тестирование мощности; o тестирование непрерывности; o тестирование безопасности. • тестирование простоты использования услуги используется, как правило, для организации работы потенциальных пользователей услуги с ограниченными возможностями, например, глухонемых или дальтоников; • тестирование соответствия контрактам и требованиям регуляторов. Тестирование проверяет, что все критерии контрактов и требования регуляторов выполнены и удовлетворены; • тестирование Управления услугами - тестирование процессов в рамках Управления услугами; • операционное тестирование - включает в себя множество тестов, зависящих от типа услуги. Типичные тесты включают: • o нагрузочные тесты и стресс-тесты - проверяют способность услуги работать на требуемом уровне на доступных мощностях. В качестве мощностей может рассматриваться полоса пропускания сети, ресурсы сервис-деска, доступные лицензии, мощность процессора, доступная память и т.п.; o тестирование безопасности - все услуги должны быть рассмотрены со стороны их влияния на аспекты безопасности организации; o тестирование восстанавливаемости - тестирование плана восстановления, который должен быть разработан для каждой услуги. регрессивное тестирование - такое тестирование повторяет успешные тесты и сравнивает вновь полученные значения с предыдущими. Оно позволяет протестировать услуги и их компоненты, которые раньше работали без сбоев и ошибок. Основные деятельности в рамках тестирования схематически показаны на рис. 10.1. увеличить изображение Рис. 10.1. Деятельности в рамках тестирования Не все деятельности в рамках тестирования выполняются последовательно, многие могут выполняться параллельно. 1. Управление тестированием. Управление тестированием включает в себя следующие действия: o планирование ресурсов для тестирования; o распределение что и когда должно тестироваться; o управление инцидентами, ошибками, проблемами, рисками; o проверка того, что известные ошибки и документация обработаны; o отслеживание прогресса и сбор данных от обратной связи с различными этапами тестирования; o осуществление незначительных изменений для уменьшения ошибок в промышленной эксплуатации; o фиксация базового состояния конфигураций; o тестирование набора метрик, анализ, ведение отчетности и управление. Метрики тестирования используются для оценки деятельностей в рамках тестирования. Они позволяют персоналу, ответственному за тестирование, контролировать прогресс и успешность тестирования. 2. Планирование и проектирование тестирования Планирование и проектирование тестирования рассматривает следующие вопросы: o обеспечение ресурсами; o программное, аппаратное обеспечение, персонал и другие мощности; o необходимые ресурсы со стороны бизнеса/заказчиков; o поддерживающие услуги; o определение дат контрольных точек; o согласованное время предоставления результатов тестирования; o точка и время приемки; o финансовые требования. 3. Проверка плана и проекта тестирования контролирует то, что: o модель тестирования предоставляет адекватные и подходящие тесты, покрывающие все риски, связанные с услугой; o модель тестирования покрывает все ключевые аспекты интеграции и интерфейсов; o сценарии тестирования точные и завершенные. 4. Подготовка среды тестирования, в том числе фиксирование базового состояния для начала тестирования. 5. Осуществление тестирования - проведение тестов с использованием ручных или автоматизированных процедур. Если тестирование провалилось, причины должны быть документированы. Тестирование должно проводиться в соответствии с принятыми планами и стратегиями тестирования. 6. Достижение критериев выхода и формирование отчета Результаты тестирования должны быть сравнены с прогнозируемыми. Они могут быть интерпретированы в терминах "прием/отклонение" тестирования; рисков для бизнеса или поставщика; изменении спроектированной ценности, вызванное увеличением издержек или уменьшением выгоды от использования услуги. По результатам тестирования формируется итоговый отчет. 7. завершение тестирования. Входами процесса Подтверждения и тестирования услуг являются: • пакет услуг; • Пакет уровня услуг (SLP); • интерфейсы поставщика услуг; • проектная документация (SDP); • планы релизов и развертывания; • критерии приемки; • Запросы на изменения. Основными выходами процесса Подтверждения и тестирования услуг являются: • формирование базового состояния конфигураций для проведения тестирования; • осуществляемые тесты; • результаты этих тестов; • анализ результатов - сравнение реальных и прогнозируемых данных, анализ выявленных в ходе тестирования рисков. Ключевые показатели производительности процесса Подтверждения и тестирования услуг: 1. первостепенные показатели отражают ценность для бизнеса и заказчиков: o раннее подтверждение того, что услуга сможет предоставлять предсказанную ценность; o уменьшение негативного влияния ошибок и инцидентов в промышленной эксплуатации; o более эффективное использование ресурсов; o уменьшение задержек в тестировании, которые влияют негативно на бизнес; o улучшение понимания новой или измененной услуги; o четкое понимание ролей и ответственностей, относящихся к новой или измененной услуге; o затраты и ресурсы, необходимые от пользователей и заказчиков. 2. второстепенные показатели - внутренние по отношению к поставщику услуг. Эти показатели отражают эффективность и результативность тестирования: o объем работ и стоимость настройки среды тестирования; o объем работ для нахождения дефектов; o уменьшение повторяющихся ошибок - достигается за счет обратной связи тестирования с проектированием и внедрением. Благодаря анализу результатов тестирования ошибки исключаются из будущих релизов; o уменьшение количества ошибок/дефектов на поздних стадиях тестирования и в процессе производства; o повторное использование данных тестирований; o количество ошибок на каждой стадии жизненного цикла; o количество и процентное соотношение ошибок, которые были обнаружены в ходе тестирования; o инциденты, найденные в ходе тестирования, как процент от общего количества инцидентов, произошедших в ходе эксплуатации; o количество известных ошибок, задокументированных на ранних стадиях тестирования. 10.2. Оценка Оценка (Evaluation) - процесс, ответственный за проведение оценки новой или изменяемой услуги для обеспечения управления рисками и помощи в принятии решения о продолжении проведения изменения[1]. Фактическая производительность услуги оценивается через сравнение с ожидаемой производительностью. Процесс также находит причины расхождения этих значений и управляет ими. Оценка фактической производительности любого изменения в услугах является важной частью сервис-менеджмента. Поставщик услуг может оценить, насколько реалистичны были его прогнозы в отношении услуг, и выявить причины несоответствия фактических значений ожиданиям. На рис. 10.2 изображен процесс Оценки, его входы и выходы. увеличить изображение Рис. 10.2. Процесс Оценки Приведем основные термины в контексте Оценки: Оценка должна рассматривать как запланированные, так и незапланированные эффекты изменения. При этом для простоты считается, что запланированные эффекты всегда приносят выгоду. Незапланированные эффекты гораздо труднее предсказать, и обычно они проявляются уже в процессе эксплуатации. Незапланированные эффекты, в отличие от запланированных, не всегда приносят пользу. Запланированные эффекты должны попадать под критерии приемки. Запланированные эффекты описываются в документации к изменению вместе с метриками, которые позволят измерить эффективность изменения. Приведем основные аспекты для оценки эффективности изменения: • Способность поставщика услуг - способность поставщика услуг или сервисной единицы осуществлять свою деятельность в соответствии с требованиями; • Переносимость - способность или мощность услуги принять изменение или релиз; • Организационное регулирование - способность организации принять предлагаемое изменение. Например, обновлены ли все имеющиеся услуги для того, чтобы гладко провести процесс внедрения новой услуги? Или: у группы внедрения есть все необходимые доступы? • Ресурсы - квалифицированный персонал, финансовые средства, инфраструктура, приложения и другие ресурсы, необходимые для внедрения услуги; • Моделирование и измерение - мера совпадения предсказанного поведения услуги (в процессе моделирования) с фактическим; • Люди - люди в рамках системы и влияние изменения на них; • Использование - подходит ли услуга для использования? Будет ли она доступной, надежной, безопасной и т.п.? • Цель - подходит ли услуга для осуществления поставленной перед ней цели? Сможет ли она предоставить требуемую производительность? Поможет ли она удалить ограничения? В управлении рисками выделяется два аспекта - оценка рисков и уменьшение рисков. Оценка рисков анализирует угрозы и уязвимости, которые появились (или появятся) в результате внедрения изменения. Основным значением при оценке рисков является вероятность угроз и ущерб, который они принесут. Риск=Вероятность*Ущерб Если посчитанный риск больше установленной нормы, необходимо принять меры по уменьшению рисков. Например, предпринять какие-то шаги для более быстрого восстановления в случае сбоев или просто устранить слабое место. После этого необходимо провести повторную оценку рисков, чтобы убедиться, что они снизились до приемлемого уровня. Результатом проведения Оценки становится отчет, состоящий из следующих секций: • перечень рисков - риски, которые остались после применения контрмер и действий по их уменьшению; • отчет по расхождениям - разница между предсказанной и фактической производительностью; • заключение об утверждении и проверки на соответствие техническим требованиям (если требуется); • рекомендации процессу Управления изменениями о том, стоит принять или отклонить изменение. Входами процесса Оценки являются пакет услуг, проектная документация, критерии приемки услуг, результаты тестов. Выходом - отчет об оценке для Управления изменениями. Ключевые показатели производительности для процесса Оценки: • со стороны заказчиков/бизнеса: o уменьшение отличий между фактической производительностью и той, которая нужна заказчикам; o уменьшение количества инцидентов, связанных с услугой. • внутренние показатели: o количество "провалившихся" проектов (должно стремиться к нулю); o уменьшение времени на проведение оценки. 10.3 Управление знаниями Управление знаниями (Knowledge Management) - процесс, отвечающий за сбор, анализ, сохранение и предоставление знаний и информации в Организации. Первичная цель Управления знаниями - увеличение эффективности путем снижения необходимости в повторном поиске знаний[1]. Знания в контексте Внедрения включают в себя: • информация обо всех заинтересованных лицах; • приемлемые уровни рисков и ожидания относительно производительности; • доступные ресурсы и временные рамки. Процесс отвечает за то, чтобы нужная информация поступала к компетентному лицу своевременно для поддержки в принятии решений. Задачи процесса: • повышение результативности поставщика услуг, качества услуг и удовлетворенности заказчиков, а также снижение затрат; • обеспечение понимания персоналом ценности предоставляемых заказчикам услуг; • обеспечение своевременного доступа персонала к следующей информации: o кто в настоящее время использует услуги; o текущие уровни потребления; o ограничения для предоставления услуги; o трудности, с которыми сталкиваются заказчики. Знания рассматриваются в рамках модели Данные-Информация-Знания-Мудрость. Данные-Информация-Знания-Мудрость (Data-to-Information-to-Knowledge-to-Wisdom или DIKW) способ представления взаимосвязей между данными, информацией, знанием и мудростью. Концепция DIKW показывает, каким образом каждое из перечисленных понятий базируется на остальных[1]. Рассмотрим термины в составе DIKW: Данные - набор дискретных фактов о событиях. В рамках Управления знаниями над ними выполняются следующие действия: 1. сбор точных данных; 2. анализ, систематизация и преобразование в информацию; 3. определение наиболее значимых данных и концентрация ресурсов на их сборе. Информация - структурированные данные. Информация, как правило, хранится в слабоструктурированных формах - документах, e-mail, файлах. Управление знаниями предназначено для того, чтобы информацию можно было легко запросить, найти и использовать. Это необходимо для исключения ошибок, облегчения поиска и предотвращения избыточных работ. Знания - комплект накопленных взглядов, опыта, идей, ценностей и суждений. Люди получают знания, опираясь на свой собственный опыт и на опыт других людей, а также путем анализа информации, поступающей из различных источников. Знания предоставляют и структурируют информацию таким образом, чтобы ее можно было легко использовать для принятия решений. В контексте Внедрения это означает использование опыта предыдущих внедрений. Мудрость - предоставляет ультимативный процесс понимания материального и способность принимать решения, основываясь на логических рассуждениях. Взаимосвязь рассмотренных понятий показана на рис. 10.3 Рис. 10.3. Преобразование данных в мудрость Знания процессов Управления услугами хранятся в Системе управления знаниями и услугами. Система управления знаниями и услугами (Service Knowledge Management System или SKMS) - набор инструментов и баз данных, которые используются для управления знаниями и информацией. SKMS включает Систему управления конфигурациями, также как и другой инструментарий и базы данных. SKMS сохраняет, управляет, обновляет, и представляет всю информацию, которая необходима поставщику услуг для управления полным жизненным циклом ИТ-услуг[1]. SKMS представляет собой большую базу знаний, которая содержит в частности: • опыт персонала; • записи об окружающей обстановке - погода, количество и поведение пользователей, фигуры производительности организации и т.п. • возможности, требования и ожидания поставщиков и партнеров: • уровень квалифицированности персонала. На рис. 10.4 показа упрощенная схема взаимодействия трех уровней обращения информации данные собираются в CMDB, поступают в CMS и только затем в SKMS для поддержки принятия решений. Рис. 10.4. Связь CMDB, CMS и SKMS Рассмотрим основные действия и принципы в рамках Управления знаниями. 1. Формирование стратегии. Для организации Управления знаниями, как и для всех предыдущих процессов, необходимо разработать стратегию. Стратегия должна рассматривать следующие вопросы: o модель управления; o планируемые и уже проводимые организационные изменения и соответствующие им изменения ролей и ответственностей; o определение ролей и ответственностей, непрерывное субсидирование; o политики, процедуры, методы и процессы для Управления знаниями; o технологические и другие требования; o метрики измерения производительности процесса Управления знаниями. Особенно внимание в стратегии должно быть уделено сбору значимых для организации знаний, данных и информации. В частности: o помощь организации в определении знаний, которые будут полезны; o проектирование структурированного процесса для организации, отбора, хранения и предоставления информации. Это позволит людям улучшить понимание значимых для организации областей; o сбор информации от разных процессов; o формирование новых знаний; o получение необходимой информации из сторонних источников; o сбор знаний из внешних источников (например, Интернета, партнеров, публикаций и т.п.) и их адаптация под нужны организации. 2. Передача знаний. Для Управления знаниями крайне важно наладить обмен информацией в рамках организации. На практике часто именно в этом заключается основная сложность. Традиционными средствами передачи знаний в рамках организации являются тренинги и документация. При построении программы тренинга необходимо учитывать множество факторов - личностные особенности, культурные и языковые отличия, возраст, специфику области и т.п. ITIL рекомендует максимально визуализировать знания с помощью компьютерных и других технологий, так как это упростит процесс обучения. При этом важно научить людей применять полученные знания на практике в зависимости от обстоятельств. 3. Управление данными и информацией. Для эффективного управления данными и информацией Управлению знаниями важно ответить на следующие вопросы: o какие знания нужны для принятия решений? o какие условия необходимо контролировать? (от погодных условий до требований законодательства); o какие данные доступны? o сколько стоит сбор и управление информацией (данными)? o применяемые политики, стандарты, требования законодательства и т.п. o интеллектуальные и авторские права. После нахождения ответов на представленные вопросы необходимо определить требования к собираемой информации. Очень часто организации накапливают большое количество данных и информации без понимания того, как они будут использованы в дальнейшем. Когда требования определены, можно построить "архитектуру информации". В ITIL под этим подразумевается выполнение следующих действий: o формирование и регулярное обновление модели управления информацией, которая позволит гибко, экономно и своевременно создавать, использовать информацию и управлять ею; o определение системы, которые позволят оптимизировать использование информации путем эффективного управления данными и информацией; o формирование системы классификации информации в рамках организации. На следующем шаге определяются процедуры управления данными и информацией. Они должны включать в себя механизмы, позволяющие: o определить данные и информацию, которые будут собираться в рамках жизненного цикла услуг; o определить процедуры управления данными и информацией и сделать их доступными для тех, кому они нужны; o хранить и восстанавливать; o устанавливать роли и ответственности для отдельных единиц информации; o определять и публиковать права, обязанности и условия, необходимые для осуществления доступа к информации и данным; o делать резервные копии информации и данных; o определить требования для пересмотра хранимых информации и данных, например, внедрение новых технологий; o собирать и хранить запросы к информации[16]. В рамках Управления данными и информацией необходимо также разработать планы по улучшению процедур и процесса в целом. 4. Использование SKMS для поддержки принятия решений в рамках организации. Важно, чтобы люди и организации, участвующие в процессе, четко понимали метрики его успешности и эффективности. Для оценки эффективности Управления знаниями можно использовать множество критериев. В общем случае критериями процесса Управления знаниями могут быть: • успешное внедрение и эксплуатация услуг с небольшим количеством ошибок; • улучшение ответов на запросы бизнеса; • улучшение доступности стандартов и политик и управления ими; • распространение знаний; • уменьшение времени и "сил", необходимых для поддержки и управления услугами; • уменьшение времени на поиск информации, необходимой для диагностирования и решения проблем и ошибок; • уменьшение зависимости знаний от персонала. Критерии для бизнеса/заказчиков: • уменьшение пользовательских ошибок в результате эффективной передачи знаний; • уменьшение времени на решение проблем в результате того, что персонал лучше обучен и может воспользоваться SKMS; • улучшения для пользователей: • быстрое разрешение запросов; • способность решения проблем без помощи извне; • проблемы и вопросы решаются на том уровне, на котором появились, и не передаются выше. • уменьшение времени внедрения и поддержки на ранних стадиях эксплуатации услуги. Критерии для поставщика услуг: • использование знаний, измеренное в: • количество запросов к SKMS; • среднее время на поиск необходимой информации. • ошибки, выявленные в ходе проверок или о которых сообщил персонал; • участие персонала в форумах для предоставления поддержки посредством сбора и обмена знаниями; • степень повторного использования процедур, проектов тестирования, сценариев и т.п, описанных в документации; • удовлетворенность персонала организацией обмена знаниями. Лекция 11: Эксплуатация услуг как этап жизненного цикла услуг Аннотация: Эксплуатация услуг как этап жизненного цикла услуг: назначение, основные принципы и результаты. Ключевые слова: эксплуатация, service, operation, функция, мониторинг, контроль, резервное копирование, печать, деятельность, объединение, ITIL, команда, цикла, план коммуникаций, стабильность, производительность, архитектура, единица, SLM, связь, потенциал, р асходы, SLR, путь, стоимость, инфраструктура Основной целью Эксплуатации услуг является координирование процессов и деятельностей, необходимых для предоставления услуг заказчикам на согласованных уровнях. Эксплуатация также ответственна за непрерывное управление технологиями, поддерживающими услуги. Даже хорошо спроектированные и внедренные процессы не принесут большой ценности в ежедневную эксплуатацию услуг, если не будут должным образом объединяться и управляться. Как часть процесса Управления услугами, Эксплуатация отвечает за эффективное использование процессов и уменьшение издержек. Как часть функционирования организации, Эксплуатация отвечает за то, чтобы бизнес смог достичь своих целей. Как часть мира технологий, Эксплуатация отвечает за эффективное использование технологий, поддерживающих услуги. Охват Эксплуатации включает в себя: • сами услуги. Любая деятельность, являющаяся частью услуги, будет предметом рассмотрения Эксплуатации. • процессы Управления услугами. В рамках Эксплуатации производится непрерывное управление многими процессами Управления услуг. Даже если они формально принадлежат другим этапам жизненного цикла услуг, например, Проектированию или Внедрению, они будут также использоваться в рамках Эксплуатации услуг. • технологии. Все услуги требуют каких-то технологий для своего предоставления. Управление этими технологиями входит в охват этапа Эксплуатации. • люди. Вне зависимости от того, какие услуги, процессы и технологии используются, всё в конечном итоге зависит от людей. Услуги предназначены для людей и управляются людьми. Непонимание важности этого аспекта может привести к провалу всего сервис-менеджмента. Эксплуатация услуг оптимизируется двумя способами: 1. долгосрочное последовательное улучшение - постоянное улучшение процессов, функций и результатов Эксплуатации. На основе анализа отчетов принимаются решения о том, где возможны улучшения, и как их лучше осуществить. Сюда относится, например, проектирование новых инструментов или процессов с помощью этапа Проектирования. 2. краткосрочное улучшение - применяемые в рамках рабочего процесса улучшения процессов, технологий и функций. Сюда относятся мелкие улучшения, не влияющие на фундаментальную основу процесса, например, обновления, тренинги и т.п. В публикации "ITILv3. Service Operation" вводятся новые термины, касающиеся эксплуатации услуг. Контроль операционного управления (IT Operations Control) - функция, отвечающая за мониторинг и контроль услуг и IT-инфраструктуры. Операционное управление IT (IT Operations) - деятельности, выполняемые функцией Контроля операционного управления ИТ, в том числе консольное управление, планирование задач, резервное копирование, восстановление, печать и управление выводом[1]. Процессы в рамках Эксплуатации: • мониторинг событий - отслеживает все события, связанные с Эксплуатацией; • управление проблемами и инцидентами - концентрируется на восстановлении нормальной работы услуг при возникновении сбоев; • выполнение запросов - разрешение запросов пользователей, которые чаще всего поступают через сервис-деск; • управление доступом - предоставление легитимным пользователям прав на доступ к услугам и предотвращение доступа неавторизированных пользователей. Более подробно процессы в рамках Эксплуатации будут рассмотрены в следующих лекциях. В публикации "ITILv3. Service Operation" вводится несколько терминов для отображения того, как люди объединяются для выполнения процессов и различных деятельностей. Функция - логическая концепция, относящаяся к людям и автоматизированным системам, которые выполняют определенный процесс, деятельность или комбинацию процессов и деятельностей. В больших организациях функция может быть разбита на части и выполняться в рамках нескольких отделов, групп или команд. Функция также может предоставляться одной организационной единицей, например, сервис-деском. В маленьких организациях, наоборот, один отдел может выполнять несколько функций. Группа - объединение людей, имеющих что-то общее. В публикации ITIL это люди, осуществляющие схожие деятельности. При этом они могут использовать разные технологии, относиться к разным организационным единицам и даже разным организациям. Команда - объединение людей, которые работают вместе для достижения общей цели, но при этом они не обязательно принадлежат одной организационной структуре. Отдел - форма организационной структуры, которая существует для выполнения определенного набора деятельностей. Управление - форма организационной структуры, в которой объединены отделы. Роль - набор ответственностей, деятельностей и полномочий, присвоенных сотруднику или команде. Роль определяется в процессе. Один сотрудник или команда может иметь (выполнять) много Ролей. Например, Роли Менеджера Конфигураций и Менеджера Изменений могут выполняться одним сотрудником[1]. Эксплуатация услуг это не просто повтор разработанных процессов и процедур. Самой сложной задачей этого этапа является обеспечение стабильной работы услуг наряду с адаптацией к изменяющимся условиям окружения IT и бизнеса. Вообще, Эксплуатация услуг часто должна искать компромиссы между взаимоисключающими друг друга вещами. В этой лекции мы рассмотрим основные из них. Интересно, что в публикации "ITILv3.Service Operation" выделено 2 взгляда на IT - внешний взгляд и внутренний взгляд. Внешний взгляд рассматривает IT как набор услуг. Это подход заказчиков и бизнеса, которым не важны технологические особенности предоставления услуг и управления ими. Им важно чтобы услуги функционировали на согласованных уровнях и приносили бизнесу заявленную ценность. Внутренний взгляд рассматривает IT как набор технологий. Он рассматривает, какие технологии и системы используются для предоставления услуг и управлениями ими. Это взгляд поставщика услуг, поэтому он и называется внутренний. При предоставлении услуг важно рассматривать две точки зрения и соблюдать баланс между ними (рис. 11.1). увеличить изображение Рис. 11.1. Баланс между внутренним и внешним взглядом Если организация будет фокусироваться только на внешнем взгляде, то есть рассматривать только требования бизнеса, она может неправильно оценить свои возможности и дать бизнесу обещания, которые не сможет в итоге исполнить. Напротив, организация, которая будет фокусироваться на внутреннем взгляде, может создать дорогие по себестоимости услуги, не приносящие бизнесу значимых результатов. В табл. 11.1 приведены примеры крайностей в обеих позициях. Таблица 11.1. Чрезмерный уклон на внутренний взгляд Позиция Чрезмерный уклон на внешний взгляд Контроль производительности и Достижение высоких уровней управление устройствами, системами, производительности услуг без понимания инфраструктурой и персоналом IT с того, как они достигаются маленькой заботой о конечном результате Метрики концентрация на технической производительности без отслеживания того, как она в итоге влияет на услуги; сообщение бизнесу значений метрик, которые не относятся к производительности услуг в целом (например, время обновления сети) концентрация на внешних метриках, без показа внутреннему персоналу как их достичь и как улучшить процессы; ожидание того, что внутренний персонал разработает собственные метрики для измерения внутренней производительности Стратегия эксплуатации стандартные механизмы на протяжении всего времени эксплуатации все новые услуги должны вписываться в существующие архитектуры и процедуры множество команд и технологий новые технологии требуют новых подходов к эксплуатации и создание новых команд операционного управления Стратегия затрат Методики и руководства снижение затрат достигается бюджет строится вокруг того, что в преимущественно за счет первую очередь нужно бизнес-единицам объединения или усиления бизнес-единицы, которые не смогли технологий четко заявить о своих нуждах или оптимизация операционных процедур неправильно их обосновали, будут и ресурсов использовать худшие услуги из-за недостаточности финансирования влияние сокращения расходов на бизнес оценивается только после его осуществления подсчет ROI(Возврата инвестиций) концентрируется на сокращении издержек и периодах окупаемости Сфокусированы вокруг Сфокусированы в основном вокруг того, непосредственного управления что и когда нужно сделать, без четких технологиями без привязки к тому, как указаний как этого достичь их производительность влияет на услуги в целом Перегиб в ту или иную сторону является недопустимым. Эксплуатация услуг должна предоставлять пользователям и заказчикам ценность. Это невозможно сделать без понимания того, как что работает. Достижение баланса между внутренним и внешним взглядом требует четкого подхода, отражающего все этапы жизненного цикла услуг: • понимание того, какие услуги использует бизнес и почему; • понимание того, как услуги влияют на бизнес; • понимание того, как используются технологии для предоставления и поддержки услуг; • вовлечение команд Операционного управления в этап Непрерывного улучшения услуг для обнаружения способов предоставления большей ценности/качества и уменьшения затрат; • формирование методик и руководств для команд Операционного управления, которые будут рассматривать вопросы управления технологиями и предоставления услуг; • Операционное управление должно четко понимать, как производительность отдельных технологий влияет на услуги в целом и, соответственно, на бизнес и его цели; • набор стандартных услуг предоставляется постоянно всем бизнес-единицам, кастомизированные услуги предоставляются отдельным бизнес-единицам; • стратегия затрат должна балансировать между требованиями различных бизнес-единиц; уменьшение затрат достигается за счет новых технологий или оптимизации использования имеющихся; • ROI должен быть основан на предоставлении ценности, а не сокращении затрат; • вовлечение Операционного управления в этапы Проектирования и Внедрения услуг; • обратная связь с этапом Непрерывного улучшения услуг для выявления возможностей и необходимости улучшений; • четкий план коммуникаций и тренингов для бизнеса. Как бы хорошо ни была спроектирована услуга, она будет функционировать хуже, если ее компоненты будут работать неустойчиво или вовсе будут недоступны. Эксплуатация услуг должна обеспечить стабильность и доступность IT-инфраструктуры в соответствии с проектной документацией. В то же время она должна распознавать изменения требований бизнеса и IT и оперативно реагировать на них. Многие изменения носят эволюционный характер. Например, функциональность, производительность и архитектура базовой системы могут измениться за несколько лет работы. Каждое такое изменение дает возможность для предоставления большей ценности бизнесу. Ответную реакцию на эволюционные изменения легче планировать. Некоторые изменения происходят очень быстро. Например, бизнес-единица выиграла тендер и ей нужны новые услуги, больше возможностей и более быстрое время реагирования. Для Эксплуатации услуг наибольшей сложностью является приспособление к таким изменениям без значительного влияния на услуги, которые уже используются. Эксплуатации услуг необходимо соблюдать баланс между обеспечением стабильности функционирования услуг и быстрым реагированием на изменения (рис. 11.2). увеличить изображение Рис. 11.2. Баланс между стабильностью и реагированием на изменения В табл. 11.2 приведены примеры крайностей двух позиций. Позиция Типичные проблемы Стратегия развития Таблица 11.2. Чрезмерная концентрация на стабильности ориентированность на технологии развитие и улучшение стандартных процессов и техник Управления услугами Чрезмерная концентрация на реагировании ориентированность на бизнес одобрение изменений без предварительного определения того, что нужно сделать для их осуществления IT может демонстрировать Персонал IT не может выполнять соответствие с SOP и OLA, даже если стандартные процедуры и есть явные расхождения с рутинные работы, так как требованиями бизнеса сконцентрирован на проектной деятельности стратегия развития основана на развитие новой технологии для анализе спроса на существующие каждого нового требования системы бизнеса сопротивление внедрению новых использование разных Технология предоставления услуг Управление мощностями услуг, которое приводит к тому, что бизнес-единицы стремятся управлять своими системами для того, чтобы получить доступ к новым услугам Использование существующей или стандартной технологии предоставления услуг; услуги корректируются для работы в рамках существующих параметров прогнозы делаются на основе текущих рабочих нагрузок производительность систем поддерживается на постоянном уровне путем обновлений и управления спросом технологий для удовлетворения требований бизнеса, которые незначительно отличаются друг от друга Избыточное обеспечение. Нет попыток приспособить новую услугу для работы в существующей инфраструктуре. прогнозы строятся на основе будущих потребностей бизнеса отдельно для каждой услуги; не принимается в расчет деятельность IT и другие услуги текущие рабочие нагрузки не учитываются Достижение баланса между стабильностью и быстрым реагированием на изменения требует выполнения следующего: • финансирование гибких технологий, таких как виртуальные среды; • построение сильного процесса Управления уровнем услуг(SLM), который будет функционировать на всем жизненном цикле услуг; • интеграция SLM с другими процессами проектирования для обеспечения корректного отображения требований бизнеса на этап Эксплуатации и компоненты IT-инфраструктуры; • инициирование изменений на ранних стадиях жизненного цикла услуг с целью совместного управления требованиями бизнеса и IT; • обеспечить участие IT в изменениях бизнеса на ранних стадиях их осуществления, чтобы IT услуги максимально соответствовали этим изменениям; • команды Операционного управления должны предоставлять информацию на вход проектирования и улучшения архитектур и услуг. Эксплуатация услуг также должна находить баланс между качеством услуг и их стоимостью. На рис. 11.3 изображена зависимость инвестиций в услуги и их качества. Рис. 11.3. Зависимость качества услуг от их стоимости Из рисунка видно, что в большинстве случаев увеличение качества услуги приводит к ее удорожанию. Тем не менее, эта связь не всегда прямо пропорциональна. Например, на ранних стадиях жизненного цикла можно значительно увеличить качество услуг путем минимальных вложений. Чем позже делаются изменения в рамках жизненного цикла, тем они дороже. На более поздних этапах жизненного цикла услуг даже малейшее увеличение качества услуги может стоить больших денег. Достижение баланса между затратами и качеством является ключевой задачей сервис-менеджмента (рис. 11.4). Универсальных решений нет, так как каждая услуга имеет разный потенциал оптимизации, зависящий от природы самой услуги и бизнес-цели, которую она поддерживает. Например, бизнес может быть готов тратить много денег на увеличение доступности критичных услуг, но его устраивает низкий уровень доступности для административных средств. К сожалению, существует множество примеров, когда организации вкладывают большие финансовые средства в увеличение качества услуг, но не получают никаких доказательств того, что оно в конечном итоге увеличивается. увеличить изображение Рис. 11.4. Баланс качества услуг и их стоимости В последние годы IT-организации стремятся сократить свои расходы чаще всего под давлением извне. Это приводит не только к уменьшению стоимости услуг, но и их качества. При этом нет простого способа расчета баланса качества и затрат. SLR(Требования уровня услуг) вместе с четким пониманием бизнес-цели и потенциальных рисков помогут определить, что услуги предоставляются с оптимальными затратами. Они также могут помочь определить услуги с "большим размером", которые возникают из-за доступности средств, и услуги "с маленьким размером", которые возникают из-за того, что бизнес не понимает необходимости финансирования тех или иных аспектов. В табл. 11.3 примеры крайностей в двух позициях. Таблица 11.3. Чрезмерный фокус на Чрезмерный фокус на стоимости качестве Позиция Предоставление качества, Максимальное сокращение затрат и которое необходимо бизнесу, предотвращение выхода за рамки чего бы это ни стоило выделенного бюджета Типичные расширение бюджета IT лимитирует качество услуг исходя из проблемы доступного бюджета IT-услуги предоставляют больше, чем требуется бизнесу бизнес стремится получить больше услуг для успеха от IT увеличение спроса на услуги с высоким качеством Управление IT не имеет метода для связи Нет метода для связи деятельностей в финансами качества услуг и их стоимости. рамках IT и непосредственного Для оценки используется чаще предоставления услуг. Финансирование всего "затраты на одного обычно выполняется в рамках расходов, пользователя" заранее предусмотренных в бюджете. Достижение баланса качества услуг и их стоимости требует следующего: • процессы и инструменты Управления финансами могут рассчитать стоимость предоставления услуг и выбрать оптимальную по стоимости модель предоставления среди имеющихся альтернатив. Например, сравнить стоимость предоставления услуги с 98% доступностью и 99,5 %, или стоимость предоставления услуг с дополнительным функционалом и без него; • обеспечение того, что решения относительно баланса качества и затрат, будут принимать люди с соответствующей квалификацией на этапах Построения стратегии и Проектирования. Менеджеры Операционного управления должны принимать решения относительно выделения финансовых средств на увеличение операционной эффективности. Следующей проблемой является баланс проактивности и реактивности. К реактивным организациям относятся те, которые не предпринимают никаких действий, пока не будет толчка в виде какого-нибудь внешнего драйвера - нового требования бизнеса, разработанного приложения или увеличения жалоб пользователей и заказчиков. К сожалению, многие организации придерживаются реактивных методов управления, наивно полагая, что это единственный путь для достижения стабильности в предоставлении услуг. Они сознательно ограничивают любые проявления проактивных действий со стороны персонала Операционного управления. Ирония состоит в том, что отсутствие одобрения проактивных действий сервис-менеджмента может привести к тому, что в итоге увеличится стоимость реактивных действий и соответствующие риски. Например, проактивным действием является формирование резервных копий серверов на случай сбоев. Это стоит не так дорого, как реактивные действия по восстановлению, если сбой все-таки случится. Проактивная организация всегда ищет пути для улучшения текущей ситуации. Проактивный подход всегда работает на перспективу и увеличивает конкурентное преимущество организации. Тем не менее, излишний уклон "в проактивность" может стоить слишком дорого. Поэтому важно соблюдать баланс двух подходов (рис. 11.5). увеличить изображение Рис. 11.5. Баланс реактивного и проактивного подходов В табл. 11.3 представлены крайности этих подходов. Позиция Таблица 11.3. Чрезмерная реактивность Чрезмерная проактивность Ответ на потребности бизнеса и Предугадывание потребностей бизнеса, инциденты только после того, прежде чем о них сообщат, и проблем, как о них сообщили/они прежде чем они появятся случились Типичные проблемы Планирование мощностей Планирование непрерывности услуг Управление изменениями подготовка к предоставлению деньги тратятся прежде, чем новых услуг занимает много устанавливаются требования. При времени, так как каждый этом многое из того, на что были проект рассматривается как потрачены деньги, никогда не будет первый использовано. похожие инциденты возникают персонал IT работает в организации вновь и вновь долго и допускает со временем, что у персонала плохой моральный знает требования бизнеса лучше, чем сам бизнес настрой и, как следствие, высокая "текучка" Ждать пока не возникнут Предугадывать проблемы с проблемы с мощностями. При мощностями и тратить деньги на то, их возникновении чтобы они не появились - даже если это предоставлять дополнительные скорее всего не случится мощности до появления следующей проблемы. Чрезмерное планирование(и траты) на никаких планов не опции восстановления IT. формируется, пока не Предоставление незамедлительного случилась катастрофа или восстановления большинства услуг, вне другое значительное зависимости от их влияния на бизнес неблагоприятное событие планы по восстановлению сфокусированы на ключевых системах IT, а не на процессах изменения запрашиваются и изменения обычно не фиксируются или фиксируются осуществляются даже при отсутствии необходимости в них - много работы в последний момент как проделывается на корректировку Срочные изменения работы элементов, которые нормально недостаточно времени на функционируют. оценку влияния и затрат изменения плохо тестируются и контролируются, как результат - большое количество последующих инцидентов Проактивное управление в общем случае имеет преимущества, но иногда требуется и реактивные действия. Для соблюдения баланса необходимо следующее: • строгие процессы Управления проблемами и инцидентами; • готовность категорировать технические сбои также хорошо, как спрос на услуги со стороны бизнеса. • доступность данных от Управления конфигурациями и Управления активами для экономии времени на реализацию проектов и принятия адекватных решений; • непрерывное вовлечение SLM в эксплуатацию услуг. Очень важно иметь обратную связь Эксплуатации с другими этапами жизненного цикла услуг. Персонал операционного управления должен принимать участие в Проектировании и Внедрении услуг, а также в Построении стратегии там, где это допустимо. Меру участия персонала необходимо определить в должностных инструкциях, ролях и т.п. Это обеспечит то, что услуги, спроектированные на этапе Проектирования, смогут быть использованы в конечном итоге. Интересным является то, что в ITIL мониторинг и контроль эксплуатации услуг сравнивается с мониторингом и контролем здоровья. IT-инфраструктура выступает в роли организма. Каждая инфраструктура имеет жизненно важные показатели, которые необходимо отслеживать, чтобы понять, работает ли инфраструктура нормально, то есть "здорова" ли она. Это значит, что для контроля не обязательно отслеживать абсолютно все компоненты, а только "жизненно важные". Это может быть использование пропускной способности сети или использование памяти на критичных серверах. Если значения этих показателей в пределах нормы, значит, система здорова. Выделение таких показателей позволит сократить расходы на мониторинг и контроль. Но, как и с другими организмами, иногда необходимо проводить комплексные проверки, которые выявят проблемы, не влияющие сразу на "жизненно важные" показатели. Какие показатели и когда необходимо контролировать в "здоровье" инфраструктуры должно быть определено на этапе Проектирования, протестировано на этапе Внедрения и оптимизировано в рамках Непрерывного улучшения услуг. Лекция 12: Управление событиями и инцидентами в рамках Эксплуатации услуг Аннотация: Процессы и деятельности в рамках этапа Эксплуатации услуг: цель, выходы и выходы, основные деятельности и ключевые показатели эффективности. В лекции рассматриваются следующие процессы: Управление событиями и Управление инцидентами. Ключевые слова: управление событиями, цикла, значение, мониторинг, SNMP, агент, значимость, ITIL, минимум, correlation, engi ne, тип триггера, уведомление о событии, механизмы, прерывание, эксплуатация, SLA, информация, процесс управления, incident, запись, категорирование, работ, очередь, деятельность, уровень поддержки, диагностика, группа, SLM В предыдущей лекции мы уже сталкивались с основными процессами этапа Эксплуатации услуг. В следующих лекциях мы познакомимся с ними более детально, рассмотрев входы, выходы, основные деятельности, ключевые показатели производительности для каждого из них. 12.1. Управление событиями Управление событиями (Event Management) - процесс,ответственный за управление событиями в течение жизненного цикла. Управление событиями одна из главных деятельностей операционного управления ИТ. Событие (Event) - изменение состояния, которое имеет значение для управления конфигурационной единицей или услугой[1]. Для того чтобы быть эффективным, операционное управление должно знать состояние инфраструктуры и ее компонентов, а также отслеживать любые отклонения от нормальной работы. Управление событиями реализовывается с помощью систем мониторинга и контроля, которые основаны на двух типах инструментов: • инструменты активного мониторинга - опрашивают ключевые конфигурационные единицы с целью выяснения их статуса и доступности. Любое отклонение вызовет алерт (предупреждение), который перенаправляется необходимой команде или инструменту для принятия необходимых действий. Приведем определение из глоссария ITIL: Активный мониторинг (Active Monitoring) - мониторинг конфигурационных единиц или услуг, использующий автоматизированные регулярные проверки для отслеживания текущего статуса объекта мониторинга[1]. • инструменты пассивного мониторинга - обнаруживают и собирают алерты, без принятия какихлибо ответных действий. Пассивный мониторинг (Passive Monitoring) - мониторинг конфигурационной единицы, услуги или процесса, который основывается на предупреждениях или уведомлениях о текущем состоянии объекта мониторинга [1]. Из определений, данных в глоссарии, не совсем очевидна разница двух видов мониторинга. Основным отличием является принятие ответных действий в случае алерта при активном мониторинге и их полное отсутствие при пассивном. Необходимо сразу отметить разницу между мониторингом и Управлением событиями. Эти процессы очень похожи, но, тем не менее, имеют отличия. Управление событиями сфокусировано на обнаружении значимых событий, касающихся статусов услуг и инфраструктуры. Мониторинг же следит за всеми событиями, и , по сути, имеет более широкий охват. Например, мониторингможет отслеживать состояние устройства, чтобы удостовериться, что оно функционирует в установленных рамках, даже если устройство не генерирует никаких событий. Таким образом, Управление событиями является частью системы мониторинга. Фактически, Управление событиями может контролировать любой аспект сервис-менеджмента. Объектами Управления событиями могут быть: • конфигурационные единицы; • условия среды (пожар или обнаружение дыма); • мониторинг использования лицензий на программное обеспечение; • безопасность; • нормальная активность (например, использование приложений или производительность сервера). Ценность Управления событиями для бизнеса косвенная. Тем не менее, можно выделить следующие преимущества, которые дает Управление событиями бизнесу: • Предоставляет механизмы для раннего обнаружения инцидентов. Во многих случаях Управление событиям позволяет обнаружить инцидент и принять соответствующие действия до того, как он значительно повлияет на услугу в целом. • При интеграции с другими процессами сервис-менеджмента может повысить их эффективность. Он может сообщить об изменениях или отклонениях статусов, что позволит соответствующей команде своевременно предпринять необходимые действия. • Раннее оповещение о необходимости обновления процедур или ресурсов; • Управление событиями основано на автоматизированных операциях, что увеличивает эффективность и позволяет задействовать персонал на более "креативные" работы, в частности, проектирование новых услуг и поиск путей по улучшению существующих[17]. Управление событиями работает со следующими типами событий: • события, сигнализирующие о регулярной операции, например: o уведомления о том, что работы в соответствии с графиком выполнены; o аутентификация пользователя для использования приложения; o e-mail достиг получателя; • • события, отмеченные как отклонения, например: o попытка входа в приложение с использованием некорректного пароля; o нестандартная ситуация в работе бизнес-процесса, которая может потребовать дальнейших действий; o использование CPU выше установленной нормы; o установка неизвестных приложений. события, отмеченные как нестандартные, но при этом не являющиеся отклонениями. При обнаружении подобных событий необходим более детальный мониторинг. На рис. 12.1 представлена схема процесса Управления событиями. увеличить изображение Рис. 12.1. процесс Управления событиями Разного рода события возникают постоянно, но при этом не все события нужно регистрировать и обнаруживать. Важно, чтобы люди, участвующие в проектировании, разработке, развертывании и поддержке услуг, четко понимали, какие именно события необходимо отслеживать. Конфигурационные единицы в большинстве случаев выдают предупреждения в случае выполнения определенных условий. Возможность формировать эти предупреждения должна быть спроектирована и встроена в конфигурационные единицы. Многие конфигурационные единицы генерируют предупреждения с использованием открытого стандарта SNMP. В идеальном случае на этапе Проектирования формируется стандартный набор событий, которые необходимо отслеживать в отношении конкретных конфигурационных единиц. В рамках этапа Внедрения этот набор тестируется и настраивается. После того, как предупреждение сформировано, специальный агент в системе обнаруживает его, "читает" и анализирует значимость события. Следующий шаг - фильтрация событий. На этом этапе выносится решение о том, будет ли данное событие проигнорировано или его необходимо передать менеджменту для осуществления необходимых ответных действий. Если событие игнорируется, оно просто записывается в журнал событий (лог). Никаких других действий не выполняется. Фильтрация является первым шагом к классификации событий. Этап фильтрации, по сути, является необязательным. Каждая организация имеет свои критерии для оценки значимости события, но ITIL рекомендует использовать как минимум три категории событий: • информационное событие - относится к событию, которое не требует никаких действий и не является отклонением. Такие события просто записываются в логи и используются для слежения за работой системы и ее компонентов, или контроля выполнения каких-то операций. Они также могут использоваться для сбора статистики и дальнейших исследований. Примерами информационных событий могут быть вход пользователя в систему или успешное завершение транзакции. • предупреждение - этот тип события формируется тогда, когда услуга или устройство приближается к пороговым значениям. Предупреждения предназначены для того, чтобы соответствующий сотрудник, процесс или инструмент проверили ситуацию более детально и приняли необходимые меры для предотвращения отклонения. Примерами предупреждений могут быть использование памяти сервера более 75% или увеличение количества коллизий в сети. • отклонение - этот тип событий сигнализирует о том, что услуга или устройство функционируют неправильно (за пределами нормы). Это значит, что нарушаются SLA и OLA, что, как следствие, приводит к негативному влиянию на бизнес в целом. Примерами отклонений могут послужить: o выход из строя сервера; o больше, чем n пользователей подключились одновременно к приложению N; o сегмент сети не отвечает на запросы. Если событие отмечено как значительное, необходимо определить точно его значимость и необходимые ответные действия - это этап корреляции. Корреляция обычно выполняется частью средства управления под названием "Correlation Engine", которая применяет к событию набор правил и критериев в определенном порядке. Основная идея в том, что событие может повлиять на бизнес, а правила помогут определить степень и тип этого влияния. В механизме корреляции событий прописывается способ реагирования на событие, например: что делаем при первом, втором и последующих проявлениях данного предупреждающего события, при сочетании или последовательности ряда событий - отклонений, одиночном, но имеющем очень серьезные для заказчика последствия, отклонении. Примеры того, что может использовать Correlation Engine для оценки: • количество похожих событий ( например, большое количество попыток неправильного ввода пароля может свидетельствовать о попытке взлома устройства); • количество конфигурационных единиц, генерирующих похожие события; • сопровождают ли событие какие-либо специфичные действия с данными или кодом; • является ли событие отклонением; • категория события; • назначение приоритета событию и т.п. Механизм, который инициирует ответные действия, называется триггером. Существует множество типов триггеров, каждый из которых спроектирован для инициализации конкретных действий. Например: • Триггеры инцидентов, которые формируют запись в Системе управления инцидентами и, соответственно, запускают процесс Управления инцидентами; • Триггеры изменений, которые формируют RFC и инициируют процесс Управления изменениями; • Скрипты, которые выполняют определенные действия, например, перезагрузку устройства; • Триггеры баз данных, которые ограничивают доступ пользователей к определенным областям базы или удаляют/создают записи в ней. Следующий этап - выбор ответных действий. Существует множество вариантов ответных действий, которые при этом могут комбинироваться. Ниже приведены примеры вариантов ответных действий: • запись события в лог. Вне зависимости от того, какое ответное действие будет выбрано, хорошей практикой является формирование записи о событии в логе. Должна быть стандартная процедура для операционного персонала, предусматривающая периодический анализ логов, а также четкие инструкции о том, как использовать конкретный лог. Также необходимо помнить о том, что информация в логах может не иметь значения до возникновения инцидента. В рамках Управления событиями нужно определить период хранения логов перед тем, как они будут заархивированы или удалены. • автоматические ответные действия. Для регулярных и "понятных" событий можно разработать автоматические ответные действия. Триггер запустит их и затем проверит результат выполнения. Если что-то пошло не так, будет сформирована запись о проблеме или инциденте. Примерами автоматических ответных действий могут быть: 1. перезагрузка устройства; 2. повторный запуск услуги; 3. изменение параметра устройства; 4. блокировка приложения для предотвращения несанкционированного доступа и т.п. • Алерт (предупреждение) и вмешательство людей. Алерт служит для уведомления о событии людей, которые имеют необходимые навыки и знания для его разрешения. При этом алерт должен содержать как можно более полную информацию о событии, на основании которой человек сможет принять правильное решение. • Создание Запроса на изменение (RFC). В Управлении событиями есть две точки, где могут быть созданы RFC: o при возникновении отклонения. Например, проверка компьютера показала, что на нем установлено три неавторизованных приложения. В этом случае необходимо сформировать RFC, который поможет процессу Управления изменениями устранить отклонение. o на этапе корреляции была определена необходимость изменения. В данном случае на этапе корреляции определяется, что наиболее подходящим ответным действием будет изменение чего-то. Создание записи об инциденте. Если Correlation Engine определяет то, что определенный набор событий является инцидентом, создается запись об инциденте. Запись об инциденте должна быть максимально полной и отражать связи со всеми событиями, относящимися к инциденту. Создание записи о Проблеме или формирование связи с уже имеющейся записью. Инциденты обычно связаны с определенными записями о проблемах. При возникновении инцидента важно связать его с соответствующей записью о проблеме, а если такой нет - создать ее. Особые типы инцидентов. В некоторых случаях событие может являться отклонением, но при этом не влиять непосредственно на услуги. Такие инциденты не включаются в расчет времени простоя и относятся скорее с проблемам операционного характера. Информация о них должна быть записана в соответствующий лог и передана персоналу, который разбирается с инцидентами этого типа[17]. Каждый день может происходить десятки и сотни событий и зачастую невозможно детально рассматривать каждое событие. Обзорные действия предназначены для проверки того, как были отработаны инциденты, не пропущены ли какие-то события, сбора статистических данных и т.п. При этом обзорные действия не должны повторять то, что было сделано до этого. Метрики, которые можно использовать для измерения эффективности Управления событиями: • количество событий по категориям; • количество событий по значимости; • количество событий, которые потребовали участия персонала; • количество инцидентов, вызванных известными ошибками и проблемами; • количество одинаковых инцидентов (или повторяющихся); • количество инцидентов, связанных с проблемами производительности; • количество инцидентов, свидетельствующих о наличии потенциальных проблем с доступностью и т.п[17]. Основными сложностями и рисками для Управления событиями являются недостаточное финансирование, выбор оптимального уровня фильтрации событий и упущение момента для своевременного развертывания агентов в рамках инфраструктуры. Для того чтобы Управление событиями было эффективным, его механизмы должны быть разработаны на этапе Проектирования услуг в рамках процессов Управления доступностью и Управления мощностями. Но при этом Управление событиями не является статичным - в ходе эксплуатации услуг могут появляться новые требования и события, которые необходимо отслеживать. Проектирование Управления событиями должно включать следующее: 1. Инструментарий - что может быть отслежено в отношении конфигурационных единиц и как можно воздействовать на них. Другими словами это точное определение и проектирование того, как контролировать и мониторить инфраструктуру и услуги. В рамках определения инструментария необходимо ответить на следующие вопросы: o что необходимо мониторить? o какой тип мониторинга необходим? o когда необходимо формировать событие? o какая информация должна содержаться в событии? o для кого предназначены сообщения о событиях? 2. Сообщения об ошибках должны отображать критичные ошибки, свидетельствующие о сбое или вероятности его возникновения. 3. Механизмы обнаружения событий и формирования алертов. Проектирование этих механизмов требует: o знания взаимосвязей всех бизнес-процессов, которые контролируются с помощью Управления событиями; o знания SLA для каждой услуги, поддерживаемой конфигурационной единицей; o знания того, кто поддерживает конфигурационную единицу; o знания того, какие значения параметров конфигурационной единицы являются нормальными, а какие нет; o понимание того, что именно нужно знать для эффективного управления конфигурационной единицей; o знания информации, которая может помочь эффективной поддержке конфигурационной единицы; o осознания важности совокупности одинаковых или похожих событий; o понимание взаимосвязей конфигурационных единиц; o доступности информации об известных ошибках, полученной от вендоров или из предыдущего опыта. 4. определение пороговых значений для каждой конфигурационной единицы. При этом значения могут изменяться в зависимости от многих обстоятельств. Например, максимальное количество пользователей, получающих доступ к серверу, зависит от того, какие именно работы они на нем выполняют. 12.2. Управление инцидентами Управление инцидентами (Incident Management) - процесс, отвечающий за управление жизненным циклом всех инцидентов. Основная цель Управления инцидентами - скорейшее восстановление услуги для пользователей. Инцидент (Incident) - незапланированное прерывание услуги или снижение качества услуги. Сбой конфигурационной единицы, который еще не повлиял на услугу, также является инцидентом. Например, сбой одного диска из массива зеркалирования[1]. Как видно из определения процесса, Управление инцидентами предназначено для максимально быстрого восстановления нормальной эксплуатации услуги и минимизации неблагоприятного влияния на бизнес в случае возникновения инцидента. Под "нормальной эксплуатацией услуги" здесь понимается эксплуатация в соответствии с SLA. Процесс рассматривает все события, которые нарушают или могут нарушить нормальную эксплуатацию услуги. Информация о таких событиях может поступать из разных источников, основными из которых являются звонки пользователей и технического персонала в сервис-деск и процесс Управления событиями. Ценность Управления инцидентами для бизнеса более очевидна, чем у других процессов этапа Внедрения. Часто именно этот процесс является основой для формирования обоснования бизнесу о необходимости остальных процессов этапа Внедрения. В частности, Управление инцидентами помогает бизнесу тем, что: • быстро находит и разрешает инциденты, в результате чего снижается время простоя услуг, что в целом увеличивает показатели доступности услуг; • выравнивает деятельности IT в соответствии с приоритетами бизнеса; • увеличивает способность выявления возможностей для улучшения услуг в результате расследования инцидентов; • сервис-деск, разрешая инциденты, определяет дополнительные требования IT и бизнеса к услугам и обучению. Время разрешения инцидента обычно формализовано в рамках SLA, OLA и других базовых соглашений. Команды поддержки должны быть готовы к соблюдению временных ограничений. ITIL вводит также понятие Модель инцидентов, которая включает в себя: • шаги, которые необходимо предпринять для того, чтобы разрешить инцидент; • хронологический порядок шагов; • распределение ответственностей - кто и что делает; • временные рамки и пороговые величины для завершения каждого действия; • вопросы того, с кем необходимо связать и на каком этапе; Таким образом, Модель инцидентов описывает последовательность действий при возникновении определенного типа инцидентов. Использование моделей инцидентов позволяет стандартизовать процесс Управления инцидентами и ускорить его. Этот подход применим в отношении часто возникающих "стандартных" инцидентов. "Нестандартные" случаи обрабатываются отдельно, например, инциденты, связанные с информационной безопасностью. В отдельную категорию выделяются "значительные инциденты", которые должны разрешаться максимально быстро. Значительный инцидент (Major Incident) наивысшая категория влияния для инцидента. Значительный инцидент означает значительные потери для бизнеса[1]. То, какие инциденты будут считаться значительными, каждая организация решает индивидуально. На рис. 12.2 схематически отображены основные деятельности в рамках Управления инцидентами. увеличить изображение Рис. 12.2. Процесс Управления инцидентами Рассмотрим основные этапы, изображенные на рис. 12.2. Для того чтобы разрешить инцидент, его необходимо сначала обнаружить, то есть идентифицировать. С точки зрения непрерывности бизнеса неприемлемо ждать обращений пользователей или технического персонала в сервис-деск. Все ключевые компоненты должны контролироваться, чтобы своевременно обнаруживать сбои или возможности их возникновения. После того, как инцидент обнаружен, информацию о нем необходимо занести в лог. В логе должно быть отображено время обнаружения инцидента, вне зависимости от того, как он был обнаружен по звонку в сервис-деск или в результате работы автоматических агентов. В логе также необходимо записать всю связанную с инцидентом информацию. Запись об инциденте должна послужить базой для его разрешения соответствующей командой поддержки. Запись об инциденте должна включать: • уникальный идентификатор инцидента; • категорию инцидента; • срочность инцидента. Срочность (Urgency) - мера того, насколько быстро с момента своего появления инцидент, проблема или изменение приобретет существенное влияние на бизнес. Например, инцидент с высоким уровнем влияния может иметь низкую срочность до тех пор, пока это влияние не затрагивает бизнес в период закрытия финансового года. Влияние и срочность используются для назначения приоритета[1]. • влияние инцидента; • приоритет инцидента; • дата и время записи; • Имя/ID человека или группы, сделавшей запись об инциденте; • метод уведомления; • имя/отдел/номер/расположение пользователя; • метод обратной связи; • описание симптомов; • статус инцидента; • связанные конфигурационные единицы; • группа поддержки/сотрудник, к кому переадресован инцидент; • связанная с инцидентом проблема/известная ошибка; • деятельности, осуществленные для разрешения инцидента; • время и дата разрешения инцидента; • категория закрытия; • время и дата закрытия[17]. Следующий этап разрешения инцидента - категорирование. Оно необходимо для дальнейших работ, в частности, поиска известных ошибок и проблем, которые могли послужить причиной для возникновения инцидента. Обычно используется три-четыре уровня категорирования (рис. 12.3). Рис. 12.3. Варианты категорирования инцидентов Нет стандартных методов для категорирования инцидентов, каждая организация сама определяет, какие категории будет использовать. Приоритет инцидента определяется исходя из двух понятий - срочности и влияния. Влияние в отношении инцидентов чаще всего определяется на основе количества пользователей, которые он затронул. Тем не менее, этот показатель не всегда является объективным. В некоторых случаях влияние инцидента даже на одного единственного пользователя может оказать значительное негативное влияние на бизнес в целом. Другие факторы, которые можно использовать для оценки влияния: • риск для жизни или сегмента; • количество услуг, которые затрагивает инцидент; • уровень финансовых потерь; • влияние на бизнес-репутацию; • возникновение нарушений законодательства и требований регуляторов. В таблицах 12.1 и 12.2 приведен пример матриц для определения приоритета инцидента и времени, в течение которого его необходимо разрешить. Таблица 12.1. Влияние Высокое Среднее Срочность Высокая 1 2 Низко е 3 1 2 3 4 5 3 4 Средняя 2 4 5 Низкая 3 Таблица 12.2. Приоритет Характеристика Время разрешения Критичный 1 час Высокий 8 часов Средний 24 часа Низкий 48 часов Планируемый Запланировать Для персонала поддержки необходимо разработать четкие инструкции определения приоритета инцидента на основе срочности и влияния на бизнес. Необходимо отметить, что приоритет инцидента может меняться в зависимости от изменения окружающих условий и требований бизнеса. Далее следует этап начальной диагностики. В первую очередь он относится к инцидентам, поступившим в сервис-деск. Специалист службы сервис-деск должен попытаться найти причину, вызвавшую инцидент, понять, что именно работает некорректно и выявить максимальное количество характеристик инцидента во время связи с пользователем, например, по телефону. Другими словами, специалист должен попытаться решить инцидент и закрыть его. Если это невозможно, он сообщает пользователю идентификационный номер инцидента. Если сервис-деск не может разрешить инцидент или сроки первой ступени разрешения инцидентов истекли, инцидент должен быть немедленно передан дальше. Эскалация (Escalation) - деятельность, направленная на получение дополнительных ресурсов, когда это необходимо для достижения Целевых показателей уровня услуги или ожиданий заказчиков. Эскалация может потребоваться в рамках любого процесса Управления услугами, но наиболее часто ассоциируется с Управлением инцидентами, Управлением проблемами и управлением жалобами заказчика. Существует два типа эскалации: функциональная эскалация и Иерархическая эскалация[1]. • функциональная эскалация. Функциональная эскалация подразумевает передачу инцидента в группу поддержки с более высокой квалификацией и компетенцией. При этом если очевидно, что второй уровень поддержки не сможет разрешить инцидент, его можно сразу передать на третий уровень поддержки. Третий уровень поддержки может включать в себя не только сотрудников организации, но и поставщиков, вендоров и т.п. При этом ответственность за уведомление пользователя о ходе разрешения инцидента остается на сервис-деске, вне зависимости от того, где инцидент рассматривается на данный момент. • иерархическая эскалация. Иерархическая эскалация подразумевает вовлечение или просто информирование руководителей более высокого уровня о возникновении инцидента. Она способствует своевременному принятию решений относительно выделения дополнительных ресурсов и вовлечения внешних организаций в процесс разрешения инцидента. Следующий этап разрешения инцидентов называется исследование и диагностика. В случаях, когда пользователи обращаются только для поиска информации, сервис-деск должен предоставить ее в минимальные сроки. Но если сообщается о наличии сбоя, это требует определенных действий по исследованию и диагностике инцидента. При этом все предпринятые действия должны быть отображены в записи об инциденте. Действия чаще всего включают в себя: • установление того, что именно не работает или что именно ищет пользователь; • определение хронологии событий; • оценка влияния инцидента, в том числе количества пользователей, которых он затронул; • поиск в базе знаний аналогичных случаев в прошлом. Когда потенциальное разрешение инцидента определено, необходимо провести тестирование того, что действия по восстановлению завершены, и услуга полностью восстановлена для пользователей. Группа, разрешившая инцидент, должна передать его на закрытие сервис-деску. Сервис-деск, в свою очередь проверяет, что все действия, необходимые для разрешения инцидента, выполнены, пользователи удовлетворены и согласны закрыть инцидент. Это включает в себя следующее: • закрытие категорирования - производится проверка корректности изначально установленной категории инцидента. Если она оказалось неправильной, ее исправление и занесение изменений в запись об инциденте; • опрос удовлетворенности пользователей - - осуществляется по звонку или электронной почте для статистики и отображения эффективности работы сервис-деска; • проверка полноты записи об инциденте; • определение того, какая проблема вызвала инцидент, является она постоянной или периодически повторяющейся. Сюда относится также определение проактивных действий по предотвращению инцидентов этого типа в дальнейшем и формирование записи о проблеме, если она новая; • формальное закрытие инцидента - формальное закрытие записи об инциденте. В некоторых случаях инцидент может быть повторно открыт даже после формального закрытия. Правильным будет заранее определить правила о том, как, когда и при каких условиях инцидент может быть повторно открыт. Это используется, в частности, когда в один и тот же день возникают одинаковые инциденты. Для нового инцидента, тем не менее, необходимо сформировать новую запись со ссылкой на предыдущий инцидент. Запись о предыдущем инциденте может быть использована для разрешения нового. Метриками эффективности процесса Управления инцидентами могут быть: • общее количество инцидентов; • количество инцидентов, находящихся на разных стадиях - закрыт, в работе, передан и т.п. • размер текущего лога об инцидентах; • количество значительных инцидентов; • среднее время разрешения инцидентов; • процент инцидентов, разрешенных в согласованное время разрешения инцидентов; • средние затраты на инцидент; • количество повторно открытых инцидентов и их процентное соотношение к общему количеству инцидентов; • количество инцидентов, неправильно назначенных в команды поддержки; • количество инцидентов, для которых были неправильно определены категории; • количество удаленно разрешенных инцидентов ( без персонального присутствия); • количество инцидентов, разрешенных с использованием каждой Модели инцидентов; • количество инцидентов в разрезе определенных интервалов дня. Для эффективного Управления инцидентами необходимо обеспечить следующее: • способность обнаруживать инциденты как можно раньше. Это включает в себя обучение пользователей немедленно сообщать об инцидентах и конфигурирование инструментов Управления событиями; • убедить персонал в том, что все инциденты должны быть занесены в журнал; • доступность информации об известных проблемах и ошибках. Это позволит персоналу использовать опыт предыдущих инцидентов; • взаимодействие с CMS для определения взаимосвязей конфигурационных единиц и обращения к их истории для поддержки первого уровня; • взаимодействие с SLM для корректной оценки инцидентов, расстановки приоритетов и выполнения процедур Эскалации. SLM в свою очередь может использовать информацию от Управления инцидентами для определения того, что целевые уровни производительности реалистичны и могут быть достигнуты[17]. Основные риски для процесса Управления инцидентами: • большое количество инцидентов, которые не могут быть разрешены в установленные сроки в связи с недостатком ресурсов или их недостаточной подготовкой; • приостановка разрешения инцидентов из-за некорректной работы поддерживающих инструментов; • недостаточность или несвоевременность информации из-за некорректной работы поддерживающих инструментов или плохой взаимосвязи с другими процессами; • несоответствия с основными контрактами и соглашениями, которые возникают вследствие их плохой проработки и нереалистичности согласованных целевых показателей. Лекция 13: Управление запросами, доступом и проблемами в рамках Эксплуатации услуг Аннотация: Процессы и деятельности в рамках этапа Эксплуатации услуг: цель, входы и выходы, основные деятельности и ключевые показатели эффективности. В лекции рассматриваются следующие процессы: Управление запросами на обслуживание, Управление проблемами и Управление доступом. В лекции также рассматриваются связи процессов Эксплуатации с другими процессами в рамках жизненного цикла услуг. Ключевые слова: значение, процесс управления, доступ, исполнение, контроль, процесс исполнения, запрос, ITIL, минимизация, запись, жизненный цикл, категорирование, определение, диагностика, поиск, CMS, диаграмма, поддержание работоспособности, база данных, управление доступом, конфиденциальность, целостность, активы 13.1. Управление запросами на обслуживание Управление запросами на обслуживание (Request Fulfillment) - процесс, ответственный за управление жизненным циклом всех запросов на обслуживание [1]. Под запросами на обслуживание понимается множество запросов пользователей к ITдепартаменту. Большинство из них имеют низкий риск, приоритет, значение для бизнеса и т.п. Именно поэтому их рассмотрение необходимо выделить в отдельный процесс, дабы уменьшить нагрузку на такие процессы как Управление инцидентами и Управление изменениями. К ним относятся, в частности, запросы на смену пароля или запросы на установку программного обеспечения. Основные цели процесса Управления запросами на обслуживание: • предоставить канал, по которому пользователи смогут направлять запросы и получать стандартные услуги по обслуживанию; • предоставить пользователям и заказчикам информацию о доступности услуг и процедуры для получения доступа к ним; • предоставлять компоненты для стандартных услуг (например, лицензии для программного обеспечения). Процесс Управления запросами на обслуживание предоставляет ценность для бизнеса тем, что поддерживает быстрый и эффективный доступ к услугам, которые персонал бизнеса может использовать для увеличения продуктивности своей работы или качества услуг и продуктов бизнеса. Централизованное исполнение запросов также позволяет увеличить контроль за услугами и их компонентами. Процесс исполнения запроса зависит от того, какой именно запрос, но тем не менее, можно выделить ряд стандартных деятельностей, которые должны быть осуществлены. При этом многие запросы периодически повторяются, поэтому можно выделить стандартную модель для их исполнения. Модель исполнения запросов включает в себя шаги по исполнению запроса, группы или отдельные люди, вовлеченные в решение, временные границы и пути эскалации. Для размещения запросов на обслуживание ITIL рекомендует разработать веб-форму. В ней необходимо предусмотреть возможность для пользователей ввести детальную и структурированную информацию о запросе из заранее определенного перечня значений. Это позволит быстро назначить запрос в команду поддержки, а иногда и автоматизировать его. Ответственность за формальное закрытие запроса на обслуживание чаще всего лежит на сервисдеске. Метриками эффективности процесса Управления запросами на обслуживание могут быть: • общее количество запросов на обслуживание; • количество запросов, находящихся на разных стадиях жизненного цикла - закрыт, в работе, назначен в команду и т.п. • количество запросов, ждущих исполнения; • среднее время исполнения запросов определенных типов; • количество запросов, исполненных в согласованные время исполнения запросов; • средние затраты на исполнение запросов определенных типов; • уровень удовлетворенности пользователей. 13.2. Управление проблемами Управление проблемами (Problem Management) - процесс, отвечающий за управление жизненным циклом всех проблем. Ключевыми целями Управления проблемами являются предотвращение инцидентов и минимизация влияния тех инцидентов, которые не могут быть предотвращены. Проблема (Problem) - причина одного или нескольких инцидентов[1]. Процесс Управления проблемами предназначен для диагностирования первопричин возникновения инцидентов и поиска решений по их устранению. Он также контролирует то, что решение проблем будет осуществлено в рамках соответствующих процессов, в частности, Управления изменениями и Управления релизами. Процесс Управления проблемами тесно связан с процессом Управления инцидентами, так как возникновение инцидентов происходит вследствие наличия проблем. Эти процессы часто используют одни инструменты, системы категорирования и расстановки приоритетов и т.п. Также как и процессы Управления инцидентами и Управления изменениями, Управление проблемами предоставляет ценность для бизнеса тем, что повышает доступность и качество услуг. Если проблема, порождающая инцидент, решена, бизнес выиграет от уменьшения времени простоя услуг и уменьшения негативного влияния на бизнес-системы. Управление проблемами также уменьшает издержки бизнеса на разрешение инцидентов, так как непосредственно уменьшает их количество. Управление проблемами состоит из двух подпроцессов: • реактивное управление проблемами, которое осуществляется в рамках Эксплуатации услуг • проактивное управление проблемами, которое инициализируется на этапе Эксплуатации услуг, но осуществляется в рамках Непрерывного улучшения услуг, следовательно, не рассматривается в этой лекции. Реактивный процесс управления проблемами изображен на рис. 13.1 увеличить изображение Рис. 13.1. Реактивное управление проблемами Рассмотрим основные этапы Реактивного управления проблемами. Первый этап - обнаружение проблемы. Существует множество путей обнаружения проблем, в частности: • обнаружение или "подозрение" причины возникновения одного или более инцидентов от сервисдеска. Сервис-деск может разрешить инцидент, но не выявить его первопричину, что увеличивает вероятность возникновения аналогичных инцидентов в дальнейшем. В этом случае формируется запись о проблеме для поиска основной причины инцидента; • анализ инцидента технической группой поддержки, в результате которого будет выявлено существование проблемы или вероятность ее существования; • автоматическое обнаружение сбоев приложений или компонентов инфраструктуры, которое выявит необходимость создания записи о проблеме; • уведомление о существовании проблемы от поставщика или подрядчика; • анализ инцидентов как часть проактивного управления инцидентами[17]. После обнаружения проблемы, информацию о ней необходимо занести в лог, то есть сформировать запись о проблеме. Запись о проблеме должна отражать детальное описание проблемы и весь ее жизненный цикл, в частности: • информация о пользователе; • информация об услуге; • информация об оборудовании; • время и дата начала формирования записи; • описание инцидента, который стал результатом существования проблемы; • детальное описание всех деятельностей в рамках решения проблемы. Категорирование проблем аналогично рассмотренному нами выше категорированию инцидентов. Определение приоритета проблемы также схоже с аналогичным этапом Управления инцидентами за исключением того, что при определении приоритета проблемы необходимо учитывать частоту и влияние инцидентов, которые она порождает. Для определения приоритета проблемы необходимо также оценить ее "тяжесть" или то, насколько она серьезна для инфраструктуры: • систему можно восстановить или она должна быть заменена? • сколько это будет стоить? • сколько людей и какой квалификации необходимо для решения проблемы? • сколько времени займет решение проблемы? • насколько велик охват проблемы? ( например, сколько конфигурационных единиц она затрагивает) На следующем этапе проводятся исследование и диагностика проблемы. Целью исследования является поиск первопричины проблемы. Для оценки точки сбоя и определения уровня негативного влияния может использоваться CMS. База известных ошибок может быть использована для поиска случаев возникновения проблемы в прошлом, и, возможно, ее решения. Иногда полезным может быть попытка воссоздания сбоя в тестовой среде для выяснения его причины и поиска наиболее эффективного пути ее устранения. Существует множество стандартных техник для анализа, диагностики и решения проблем. Приведем техники, рассматриваемые в публикации ITIL: • хронологический анализ. Когда возникает сложная проблема, могут появиться противоречивые отчеты и сообщения относительно того, что действительно случилось. Для восстановления картины документально фиксируют хронологию всех событий, связанных с проблемой. Это помогает также выяснить зависимости и устранить из цепочки события, которые не относятся к рассматриваемой проблеме. • Анализ потерь (Pain Value Analysis) - методика, используемая для идентификации влияния на бизнес одной или нескольких проблем. Формула расчета потерь основана на количестве затронутых пользователей, продолжительности простоя, влияния на каждого пользователя, и стоимости для бизнеса (если известно). • Анализ Кепнера и Трего - системный подход к разрешению проблем. Проблема анализируется в терминах Что, Где, Когда и Сколько. Определяются возможные причины. Наиболее вероятная причина подвергается проверке. Таким образом определяется истинная причина. • "Мозговой штурм" - методика, которая помогает команде генерировать идеи. При этом идеи не должны критиковаться и анализироваться во время проведения самого Мозгового штурма, это происходит после. • Диаграмма Ишикавы - методика, помогающая команде определить все возможные причины проблемы. Первоначально была разработана Каору Ишикавой (Kaoru Ishikawa), результатом работы этой методики является диаграмма[1]. Основная проблема изображается в виде ствола диаграммы, главные факторы - как ветки, вторичные факторы - как соплодие и т.д. Создание диаграммы стимулирует обсуждение проблемы и более глубокое понимание ее сложности. • анализ Парето - методика отделения значимых причин возникновения проблемы от незначимых. Должны быть предприняты следующие действия: 1. сформировать таблицу, содержащую причины проблемы и их частоту в процентном соотношении от общего количества случаев возникновения проблемы; 2. упорядочить строки таблицы в порядке увеличения важности причин; 3. добавить столбец совокупного процента. Более понятным анализ Парето будет на примере из публикации ITIL. В табл. 13.1 приведены 10 причин отказа сетевых взаимодействий, то есть "падения сети". Таблица 13.1. "Падение сети" Причины Процент от общего количества Расчет Совокупный процент (%) (%) Сетевой контроллер 35 0+35 35 Порча файлов 26 35+26 61 Конфликт адресации 19 61+19 80 ОС Сервера 6 80+6 86 Ошибки скриптов 5 86+5 91 Непротестированное изменение 3 91+3 94 Ошибки оператора 2 94+2 96 Сбой резервного копирования 2 96+2 98 Попытки вторжения 1 98+1 99 Сбой дисков 1 99+1 100 Далее необходимо сделать следующие шаги: 4. создать столбиковую диаграмму причин, расположенных в соответствии с их Процентом от общего количества ( 2 столбец); 5. наложить линию суммарного процента (4 столбец). 6. нарисовать линию от 80 % совокупного процента к оси y, параллельно оси x. В точке пересечения с линией суммарного процента "уронить" ее на ось x. Точка оси x, на которую "упадет" линия отделит значимые причины от незначимых. Диаграмма рассматриваемого примера изображена на рис. 13.2. Рис. 13.2. Анализ Парето Следующий этап - поиск обходного решения. Обходное решение (Workaround) - уменьшение или устранение влияния инцидента или проблемы, для которых в текущий момент недоступно полное разрешение[1]. Например, перезапуск отказавшей конфигурационной единицы или ручное добавление поврежденного файла из резервной копии. Обходные решения являются временными решениями для поддержания работоспособности системы на время поиска решения проблемы. Обходные решения документируются в Базе известных ошибок. База известных ошибок (Known Error Database или KEDB) - база данных, содержащая все записи об известных ошибках. Эта база данных создается в процессе Управления проблемами и используется процессами Управления инцидентами и проблемами. База известных ошибок это часть Системы управления знаний по услугам (SKMS) [1]. Как только найдено решение проблемы, его необходимо как можно быстрее реализовать. Тем не менее, важно помнить, что внесение изменений может затронуть другие услуги или конфигурационные единицы. Если необходимо какое-то функциональное изменение, прежде чем его осуществить, надо сформировать Запрос на изменение, который будет обработан в рамках процесса Управления изменениями. После того, как все необходимые действия предприняты, проблема устранена, происходит закрытие записи о проблеме, а также всех связанных с ней записей об инцидентах. Перед закрытием необходимо провести проверку (пересмотр) полноты записи о проблеме - она должна содержать детальное описание всех осуществленных процедур и действий. Для значительных проблем, которые считаются таковыми в соответствии с системой приоритетов конкретной организации, проверка должна быть более детальной, в частности рассматривать такие вопросы как: • что сделано правильно в отношении проблемы; • что сделано неправильно в отношении проблемы; • что может быть сделано лучше в будущем; • как предотвратить повторение проблемы; • были ли задействованы третьи стороны. На практике редко встречаются приложения, системы и релизы программного обеспечения, не имеющие ошибок. В идеальном случае все они обнаруживаются на этапе тестирования. Тем не менее, ошибки могут не проявится или быть незамеченными и , таким образом, "просочиться" на этап эксплуатации. Для оценки эффективности процесса Управления проблемами можно использовать следующие метрики: • общее количество проблем, зафиксированных в определенный период; • процент проблем, решенных в рамках, установленных SLA; • количество проблем, решение которых вышло за рамки согласованных целевых показателей времени для решения проблем; • количество нерешенных проблем; • среднее время решения проблемы; • количество значительных проблем; • количество успешно завершенных пересмотров значительных проблем; • количество известных ошибок, добавленных в Базу известных ошибок. 13.3 Управление доступом Управление доступом (Access Management) - процесс, отвечающий за допуск пользователей к использованию услуг, данных или других активов. Управление доступом помогает обеспечить конфиденциальность, целостность и доступность активов за счет того, что только авторизованные пользователи имеют возможность получить доступ или модифицировать активы[1]. Основным драйвером процесса является процесс Управления информационной безопасностью, так как именно он формирует политики и правила, которые реализуются процессом Управления доступом. Управление доступом предоставляет ценность бизнесу благодаря тому, что: • каждый сотрудник имеет уровень доступа, необходимый для выполнения своих обязанностей; • контролируемый доступ к активам позволит организации поддерживать необходимый уровень конфиденциальности информации; • уменьшение вероятности ошибочных действий при работе с данными или использовании критичной услуги; • аудит использования услуг и отслеживание некорректной работы с ними; • быстрое лишение прав при возникновении необходимости; • может понадобиться для обеспечения соответствия требованиям регуляторов. Рассмотрим последовательность деятельностей для предоставления доступа. 1. запрос доступа (или его ограничение) может быть осуществлен через следующие механизмы: o стандартный запрос от Отдела кадров (HR). Например, при найме нового сотрудника, увольнении, переводе в другой отдел и т.п.; o Запрос на изменение (RFC); o Запрос на обслуживание переданный рассмотренным выше процессом Управления запросами на обслуживание; o в процессе выполнения авторизованного сценария или опции (например, скачивание приложения с центрального сервера). 2. Верификация запроса на получение доступа включает в себя проверку двух категорий: o пользователь, запрашивающий доступ, действительно тот, за кого себя выдает; o пользователь, запрашивающий доступ, имеет право его получить; Первый пункт проверяется обычно с помощью предоставления имени и пароля - они доказывают то, что пользователь является легитимным. В некоторых организациях могут быть использованы eToken, биометрическая аутентификация и т.п. Идентификатор (Identity) - уникальное наименование, используемое для идентификации пользователя, человека или роли. Идентификатор используется для предоставления прав пользователю, человеку или роли. Примерами идентификации могут быть имя пользователя Иванов Иван или Роль "Менеджер Изменений" [1]. Вторая категория требует некоторой независимой проверки, не связанной с запросом. Например: o уведомление от Отдела кадров о том, что это новый сотрудник и ему необходим доступ к стандартному набору услуг; o уведомление от Отдела кадров о том, что сотрудник получил повышение по службе и ему необходим доступ к дополнительным услугам; o подтверждение от соответствующего процессу менеджера; o предоставление запроса на обслуживание (с обоснованием) через сервис-деск; o предоставление запроса на изменение через процесс Управления изменениями; o политика безопасности, в которой оговорено то, что пользователи могут получить доступ к услугам, если они им необходимы. Для новых услуг должны быть четко определены пользователи и группы, которые будут иметь к ним доступ. 3. Предоставление доступа. Управление доступом не принимает решений относительно того, кто и куда будет иметь доступ. Процесс только реализует политики и правила, определенные на этапах Проектирования или Построения стратегии. После верификации пользователя, Управление доступом предоставит ему доступ для использования запрошенной услуги. В большинстве случаев непосредственное предоставление доступа требует действий со стороны каждой команды, поддерживающей услугу. Поэтому при проектировании услуг лучше предусмотреть автоматизацию процесса предоставления доступа. 4. Мониторинг статуса идентичности Пользователи, работающие в организации, и их роли могут меняться. Примерами изменения могут быть: o изменение обязанностей - в этом случае пользователю может понадобиться доступ к другому набору услуг или просто к дополнительным услугам; o повышение или понижение в должности - в этом случае пользователю обычно необходим доступ к тому же набору услуг, но с другими уровнями; o перевод - в этом случае пользователю чаще всего нужен будет тот же набор услуг, но в другом регионе и с другими данными; o отставка или смерть - в этом случае все доступы должны быть немедленно аннулированы; o выход на пенсию - в этом случае доступы либо аннулируются, либо ограничиваются. Например, сотрудник, вышедший на пенсию, может иметь доступ к услугам по покупке продуктов своей компании по сниженной цене; o дисциплинарное ограничение - временное ограничение доступа пользователя из-за какой-то провинности; o увольнение - в этом случае доступы должны быть немедленно аннулированы во избежание инцидентов безопасности. 5. Мониторинг доступа Управление доступом ответственно не только за непосредственное предоставление доступа, но и за контроль его использования. Поэтому функция контроля доступа должны быть предусмотрена в рамках деятельностей мониторинга. Если возникают какие-то нарушения, они характеризуются как инциденты безопасности. Управление доступом принимает участие в определении настроек систем обнаружения вторжений (IDS). 6. Отзыв или ограничение прав Наряду с предоставлением доступа, Управление доступом ответственно за его аннулирование или ограничение. Аннулирование доступа происходит в таких случаях как смерть, увольнение, сокращение, кардинальное изменение обязанностей и т.п. В ряде случаев полностью лишать сотрудника доступов не требуется, но есть необходимость в их ограничении. Например, при понижении сотрудника в должности. 13.4. Взаимосвязь процессов Эксплуатации с другими этапами жизненного цикла Управление изменениями Несмотря на то, что Управление изменениями рассматривается в рамках этапа Внедрения, персонал Эксплуатации услуг должен принимать участие в следующем: • инициализация и передача на рассмотрение Запросов на изменения (RFC), которые позволят разрешить проблемы, возникающие в процессе Эксплуатации; • участие во встречах с руководством для обсуждения позиции, рисков и проблем Эксплуатации; • участие в реализации изменений в соответствии с предписаниями Управления изменениями; • осуществление "откатов" в соответствии с предписаниями Управления изменениями ( в случае неудачных изменений); • обеспечивать поддержку в определении и управлении моделей изменений, которые имеют отношение к компонентам и услугам этапа Эксплуатации; • получение расписаний изменений и подготовка к ним персонала; • использование процесса Управления изменениями для стандартных операционных изменений. Управление конфигурациями Также как и Управление изменениями, Управление конфигурациями рассматривается в рамках этапа Внедрения. Тем не менее, персонал Эксплуатации услуг вовлечен в следующее: • информирование Управления конфигурациями о найденных несовпадениях между фактическим состоянием конфигурационных единиц и информацией в Системе управления конфигурациями (CMS); • осуществление действий по исправлению найденных несоответствий под контролем Управления конфигурациями. Управление релизами и развертыванием Персонал Эксплуатации участвует в следующем: • осуществление всех необходимых действий под контролем Управления релизами и развертыванием в вопросах, касающихся компонентов и услуг этапа Эксплуатации; • участие в планировании значительных релизов для того, чтобы были учтены все проблемы, которые могут возникнуть непосредственно на этапе Эксплуатации; • помещение/удаление компонентов в Библиотеку эталонного ПО (DML). Управление мощностями Как мы уже знаем, Управление мощностями работает на трех уровнях - Управление мощностями бизнеса, Управление мощностями услуг, Управление мощностями ресурсов: • В рамках Управления мощностями бизнеса персонал Эксплуатации взаимодействует с представителями бизнеса для планирования/обсуждения долгосрочных и краткосрочных вопросов и проблем, которые могут затронуть мощности IT; • В рамках Управления мощностями услуг этап Эксплуатации помогает более детально оценить характеристики каждой услуги, а также потребность пользователей или транзакций в услугах и инфраструктуре (в частности, в зависимости от времени); • В рамках Управления ресурсами этап Эксплуатации помогает более детально оценить показатели производительности/мощности, а также степень утилизации отдельных конфигурационных единиц. Помимо рассмотренных аспектов, которые в большей степени имеют отношение к построению стратегии и планированию, операционный персонал выполняет ряд "повседневных" деятельностей, которые формально являются частью Управления мощностями, но осуществляются операционным персоналом. • Мониторинг мощности и производительности для обнаружения проблем и предотвращения сбоев. Мониторинг должен быть максимально автоматизирован. • Управление проблемами, связанными с производительностью и мощностью. • Хранение данных Управления мощностями, которые формируются в процессе мониторинга. • Управление спросом к отдельным ресурсам и услугам. Большинство вопросов управления спросом должно быть рассмотрено в рамках Проектирования, тем не менее, есть ряд вопросов, которые могут решаться на этапе Эксплуатации. Например, если с производительностью какой-то услуги возникают проблемы, персонал Эксплуатации услуг может ввести ограничение на количество пользователей, которые могут использовать услугу одновременно, до тех пор, пока проблемы не будут решены. • Управление рабочей нагрузкой рассматривает вопросы оптимизации ресурсов инфраструктуры для увеличения производительности. Например, составление расписаний для отдельной услуги или ее перемещение с одних конфигурационных единиц на другие. • Планирование мощностей. Персонал Эксплуатации услуг должен принимать участие в составлении планов мощностей. Управление доступностью. На этапах Внедрения и Проектирования определяются уровни доступности, которые необходимо обеспечить для услуг. Этап Эксплуатации ответственен за непосредственное предоставление услуг на этих уровнях пользователям. При эксплуатации услуг может выясниться, что согласованные уровни доступности недостижимы или не являются оптимальными. Информация о несоответствиях поступает на этап Непрерывного улучшения услуг для осуществления корректирующих действий. Кроме того, персоналу операционного уровня иногда необходимо проводить работы, которые требуют остановки услуг, например, для обновления. Расписание таких работ должно быть доведено до персонала Управления доступностью. Управление знаниями. Информация с этапа Эксплуатации, которая имеет значение в перспективе, должна быть занесена в Систему управления знаниями по услугам (SKMS). Финансовое управление. Персонал Эксплуатации услуг должен принимать участие в обосновании необходимости финансирования. Также при введении мер по сокращению издержек, в обязанности Эксплуатации услуг входит контроль за тем, чтобы эти меры не повлияли существенно на предоставление услуг. Управление непрерывностью услуг. Эксплуатация услуг ответственна за тестирование планов восстановления и их реализацию в случае возникновения необходимости. Лекция 14: Непрерывное улучшение услуг как этап жизненного цикла услуг Аннотация: Непрерывное улучшение как этап жизненного цикла услуг: назначение, основные принципы и результаты. Ключевые слова: улучшение, ITIL, этап жизненного цикла, производительность, CSI, бизнеспроцессы, отношение, gap, SLM, определение, sip, затраты, программа, ROI, цикла, жизненный цикл, интеграция, связь, ITSM, информация 14.1. Непрерывное улучшение услуг как этап жизненного цикла услуг Несмотря на то, что Непрерывное улучшение услуг в ITIL выделено в отдельный этап жизненного цикла, фактически это процесс, который сопровождает услугу на всем ее жизненном цикле. Непрерывное улучшение услуг (Continual Service Improvement или CSI) постоянное улучшение услуг отвечает за управление улучшениями (совершенствованием) в процессах Управления услугами и предоставлении услуг. Производительность поставщика услуг постоянно измеряется, и разрабатываются меры по улучшению процессов, услуг и ИТинфраструктуры с целью увеличения эффективности, результативности и эффективности затрат[1]. Основной целью CSI является непрерывное "выравнивание" услуг в соответствии с изменяющимися требованиями бизнеса путем поиска и реализации возможностей улучшения услуг, которые поддерживают бизнес-процессы. Задачи Непрерывного улучшения услуг: 1. обзор, анализ результатов и формирование рекомендаций по улучшениям для каждого этапа жизненного цикла: Построения стратегии, Проектирования, Внедрения и Эксплуатации услуг; 2. обзор и анализ полученных результатов на уровне услуг; 3. поиск возможностей и осуществление соответствующей деятельности по увеличению качества услуг и результативности/эффективности процессов Управления услугами; 4. увеличение эффективности затрат без негативного влияния на удовлетворенность заказчиков предоставляемыми услугами; 5. использование подходящих методов управления для поддержки деятельностей в рамках Непрерывного улучшения услуг. На рис. 14.1 представлена схематическая модель Непрерывного улучшения услуг. Рис. 14.1. Модель CSI Возможности для улучшения услуг есть всегда. Процесс улучшения может быть сведен к шести шагам: 1. понять и принять общую цель организации; 2. оценить текущую ситуацию и получить объективную и аккуратную оценку того, в каком состоянии находится организация. Оценка базового состояния представляет собой анализ текущего состояния в контексте бизнеса, организации, персонала, процессов и технологий. Базовое состояние здесь обозначает собой некую отправную точку для измерения эффекта от реализации улучшений; 3. расставить приоритеты улучшения на основе более глубокого анализа цели организации; 4. определить план CSI для процессов сервис-менеджмента; 5. проверить метрики и системы измерения, которые позволят осуществить контроль в промежуточных точках реализации улучшений, измерить гибкость процессов и достижение приоритетов и целей бизнеса на уровне услуг; 6. в завершение, необходимо убедиться в том, что предложенные изменения реализованы, увеличение качества достигнуто и может быть сохранено в дальнейшем. Улучшение не всегда можно объективно оценить. Восприятие играет ключевую роль в определении успеха любой инициативы по улучшению. При этом у заказчиков и поставщиков услуг может сложиться разное отношение к улучшению, то есть образоваться так называемый "разрыв" (англ. gap). Для того чтобы уменьшить или предотвратить появление разрыва, CSI необходимо доводить отчеты до всех заинтересованных сторон. На рис. 14.2 представлены наиболее часто встречающиеся "разрывы" между восприятиями заказчика и поставщика услуг. Рис. 14.2. Разница восприятий улучшение поставщиком и заказчиком Управление "разрывами" является задачей SLM. Именно SLM ответственен за обнаружение существующих или потенциальных "разрывов" и определение необходимости формирования Плана по улучшению (SIP). Обычно самые большие расхождения встречаются между тем, что хочет заказчик, что он получает в итоге и за что готов заплатить. Результаты улучшения услуг обычно определяются в 4 терминах: • улучшения - результаты, которые при сравнении с предыдущим состоянием могут показать увеличение желаемой или уменьшение нежелаемой метрики. Например, компания X снизила на 25 процентов количество неудавшихся изменений путем внедрения процесса Управления изменениями ; • выгоды - результаты, достигнутые в результате реализации улучшений, обычно выраженные в финансовых терминах. Например, уменьшение на 25 процентов количества неудавшихся изменений позволило сэкономить 1500000 рублей; • ROI (Возврат инвестиций) - измерение ожидаемых выгод от инвестиций. В данном контексте это разница между выгодой, полученной от улучшения, и затратами на его реализацию. Например, компания потратила 1000000 р для внедрения процесса Управления изменениями, который в итоге принес выгоду в 1500000 р. ROI в первый год будет 50%; • VOI (Добавленная ценность от инвестиций) - измерение ожидаемых выгод от инвестиций. VOI рассматривает как финансовые, так и нематериальные выгоды[1]. ROI является частью VOI. Например, организация X внедрила строгий процесс Управления изменениями за 1000000р. Уменьшение количества неудавшихся изменений увеличило способность организации быстро реагировать на потребности заказчиков и изменения условий окружения. Существует ряд выгод, которые очень трудно поддаются оценке - нематериальные выгоды. Сюда можно отнести, например, улучшение репутации и увеличение удовлетворенности заказчиков. На практике, чтобы существовать, CSI должен постоянно доказывать бизнесу свою ценность и необходимость. Для этого необходимо четко определить цель процесса и понятные бизнесу улучшения, которые последуют за его реализацией. Перед утверждением любого улучшения организация должна сравнить затраты на его реализацию и выгоды, которые оно предоставит. Рассмотрим подробнее выгоды, которые может принести реализация улучшения: • выгоды заказчика/бизнеса o улучшение качества бизнес-операций путем улучшения качества услуг, которые их поддерживают; o более надежная поддержка бизнеса, предоставляемая процессами Управления инцидентами, проблемами и изменениями; o заказчики будут знать, чего ожидать от IT, и что требуется от них; o увеличение продуктивности работы персонала вследствие увеличения надежности и доступности услуг; o процедуры обеспечения непрерывности IT сфокусированы на поддержке непрерывности бизнеса и соответствуют потребностям бизнеса в обеспечении постоянной доступности; o улучшение взаимодействия поставщика услуг и заказчика; o увеличение удовлетворенности пользователей, так как заказчик лучше понимает их и предоставляет то, что от него требуется; o увеличение качества и доступности услуг, которое в свою очередь увеличивает доходы и продуктивность бизнеса; o улучшение процессов планирования закупок, развертывания и реализации; o улучшение управления информацией в отношении бизнес-процессов и IT-услуг; o увеличение гибкости бизнеса через улучшение понимания поддержки, которую оказывает IT; o улучшение соответствия целей IT и бизнеса; o увеличение гибкости и адаптивности услуг; o улучшение реакции на потребности бизнеса; o • ускорение и улучшение реализации проектов, развертываний и изменений. финансовые выгоды: o оправданные по затратам инфраструктура и услуги; o прибыльное предоставление услуг; o CSI, как правило, имеет долгосрочные финансовые выгоды, например: уменьшение затрат на реализацию изменений; уменьшение негативного влияния на бизнес в процессе реализации IT-изменений; услуги будут спроектированы для достижения конкретных требований, ни больше, ни меньше; улучшение надежности, доступности и непрерывности услуг; расходы на обеспечение непрерывности IT-компонентов будут соизмеримы с критичностью бизнес-процессов, которые они поддерживают; улучшенное распределение и использование ресурсов. • инновационные выгоды o четкое понимание требований бизнеса обеспечит то, что услуги будут успешно поддерживать бизнес-процессы; o улучшение качества информации о состоянии услуг; o увеличение гибкости бизнеса за счет улучшенного понимания роли IT в поддержке бизнеса; o увеличение гибкости и адаптивности услуг; o увеличение способности быстро находить новые направления, обнаруживать изменения в окружении бизнеса и адаптироваться к ним; o увеличение уверенности бизнеса в поставщике услуг. • внутренние выгоды IT-организации o улучшенные метрики и формирование управленческих отчетов; o выравнивание структуры затрат в соответствии с потребностями бизнеса; o улучшение качества информации относительно текущего состояния услуг и о том, где изменения принесут наибольшую выгоду; o улучшенные связи, командная работа и "взаимоактивность" IT и заказчиков; o повышение эффективности работы персонала; o увеличение эффективности процессов; o четко определенные роли и ответственности; o четкое понимание текущих возможностей IT и потенциала услуг; o CSI процедуры сфокусированы на осуществлении инкрементальных и значительных улучшений как услуг, так и процессов управления услугами; o структурированный подход к управлению данными, их преобразованию в информацию и знания, который в итоге позволит получить опыт для выявления возможностей по улучшению услуг; o оптимизация использования ресурсов; o знания о том, какие инструменты и ресурсы необходимы для поддержи CSI; o улучшение информации о текущем состоянии услуг; o улучшение мотивации персонала; o более проактивное развертывание и улучшение технологий и услуг; o услуги и системы проектируются для достижения реальных бизнес-целей в установленные сроки; o улучшение управления поставщиками и улучшение производительности поставщиков; o уменьшение случаев невыполнения обязательств по соглашениям, договорам и т.п.; o улучшение взаимоотношений с бизнесом[18]. Любая программа по улучшению должна периодически переоцениваться с помощью ROI или VOI. Для того чтобы CSI был успешным, очень важно осуществлять улучшения на всех этапах жизненного цикла услуг. Например, если CSI сконцетрируется только на улучшении непосредственной эксплуатации услуг, в итоге его успех будет крайне ограниченным. Это как сбивать температуру при простуде, вместо того, чтобы лечить саму болезнь. Если CSI будет действовать только в отношении операционных проблем, фактически, он будет избавлять от симптомов, вместо того, чтобы решать проблемы, их породившие. Большинство проблем берут начало на этапах Построения стратегии и Проектировании услуг. Именно поэтому CSIдолжен рассматривать жизненный цикл услуг в целом. Рассмотрим взаимосвязь CSI с другими этапами жизненного цикла: • Построение стратегии предназначено для формирования стратегического подхода организации, стандартов и политик, которые будут использованы для проектирования и предоставления услуг. Возможности для улучшения на этом этапе могут появиться, прежде всего, благодаря внешним факторам, например, изменению требований регуляторов, новым стратегиям поглощений или изменениями в технологиях. Источником информации для улучшения может также послужить обратная связь с другими этапами жизненного цикла услуг. • Проектирование услуг предназначено для создания или изменения услуг и архитектуры инфраструктуры в соответствии с потребностями бизнеса. Проектирование услуг трансформирует решения первого этапа в предоставляемые услуги. Новые стратегии, архитектуры, политики и требования бизнеса могут стать драйверами для инициализации CSI на этом этапе. • Внедрение услуг управляет передачей услуг в промышленную эксплуатацию. Ключевыми процессами этого этапа являются Управление изменениями и Управление конфигурациями. Возможности для улучшений появляются при внедрении новых стратегий и дизайнов. • Эксплуатация услуг управляет ежедневной эксплуатацией услуг. Этап ответственен за мониторинг и формирование отчетности относительно использования услуг. На основе сформированной информации выносятся решения о необходимости тех или иных улучшений. На рис. 14.3 показана интеграция CSI в жизненный цикл услуг. увеличить изображение Рис. 14.3. CSI и жизненный цикл услуг Подводя итог можно сказать, что возможности для улучшения услуг есть всегда и организации не нужно ждать, пока услуги поступят в промышленную эксплуатацию. То есть каждый жизненный цикл предоставляет информацию для следующего жизненного цикла. То же самое действует в отношении CSI. Для того чтобы быть эффективным, CSI должен иметь открытую и, что немаловажно, честную обратную связь с персоналом IT. Опросы и обзоры могут послужить хорошими способами для сбора информации о том, что действительно получилось от реализации того или иного улучшения. Использование выходов различных процессов в рамках ITSM позволит сформировать целостный взгляд на проектирование и эксплуатацию услуг. Эта информация в комбинации с новыми требованиями бизнеса, технологиями, возможностями IT, бюджетом и требованиями регуляторов будет необходима CSI для определения того, что именно необходимо улучшить и как это сделать. Сам по себе CSI не сможет достичь значительных результатов без активного участия персонала с других этапов жизненного цикла. Для целостного подхода к улучшению услуг необходимо внедрять инициативы и деятельности CSI в каждый этап жизненного цикла. 14.2. Основные принципы непрерывного улучшения услуг Улучшение услуг предназначено для увеличения результативности и эффективности и снижения затрат на услуги и поддерживающие их процессы ITSM. В этой лекции мы рассмотрим основные принципы CSI. 1. CSI и изменение организации CSI в общем случае является частью глобального процесса, который в публикациях ITIL называется "изменением организации". Любое изменение организации является затратным и трудным процессом, встречающим на своем пути множество проблем. Основная проблема, как правило, связана с людьми, которые не любят изменения. Изменения в общем случае заставляют персонал отказываться от привычных практик работы. ITSM должен донести до каждого сотрудника необходимость изменения и его потенциальную выгоду. 2. Владение и управление Принцип владения заключается в том, что для любого улучшения необходим человек, который будет им "владеть". Эта роль называется менеджер CSI. Менеджер CSI ответственен за то, что для реализации улучшения будут использованы лучшие и наиболее оптимальные подходы. Владелец CSI ответствен за успешность реализации улучшений в рамках организации. Такое распределение ролей позволит не просто использовать лучшие практики, но и гарантировать, что они могут быть успешно внедрены с учетом имеющихся ресурсов. 3. Определение ролей Роли можно разделить на две группы - роли, связанные с промышленной эксплуатацией услуг, и роли, связанные с проектированием услуг. Роли, связанные с эксплуатацией, реализуют CSI в качестве способа дальнейшего существования. Другими словами, они решают проблемы, постоянно возникающие при эксплуатации услуг. Роли, связанные с проектированием услуг, используют более классический подход к реализации CSI посредством программ и проектов. Как правило, сюда относятся роли, занимающие верхние ступени иерархии в проектировании и адаптации услуг и процессов. 4. Внутренние и внешние драйверы Драйверы для улучшения услуг можно разделить на внешние и внутренние. К внешним, например, относятся требования регуляторов, законодательства, внешних заказчиков и условия рынка. К внутренним можно отнести особенности конкретной организации, ее стратегию, возможности, способность адаптироваться к изменениям и т.п. При этом рассмотренные аспекты могут не только способствовать улучшению, но и препятствовать ему. 5. Управление уровнем услуг (SLM). SLM является связующим звеном между бизнесом и поставщиком услуг, и CSI должен принимать его и соответствовать ему. 6. Цикл Деминга Цикл Деминга, более известный как PDCA ("Plan-Do-Check-Act"), представляет собой циклически повторяющийся процесс принятия решения. Методология PDCA представляет собой простейший алгоритм действий руководителя по управлению процессом и достижению его целей. Цикл управления включает в себя 4 этапа: o Планирование - установление целей и процессов, необходимых для достижения целей, планирование работ по достижению целей процесса и удовлетворения потребителя, планирование выделения и распределения необходимых ресурсов. o Выполнение - выполнение запланированных работ. o Проверка - сбор информации и контроль результата на основе ключевых показателей эффективности (KPI), получившегося в ходе выполнения процесса, выявление и анализ отклонений, установление причин отклонений. o Корректировка - принятие мер по устранению причин отклонений от запланированного результата, изменения в планировании и распределении ресурсов. Рис. 14.4. Цикл Деминга 7. Измерение Концепция измерения результата является фундаментальной основой CSI.Для того, чтобы измерить успешность того или иного улучшения, ITIL вводит понятие базовое состояние (baseline). Базовое состояние является отправной точкой для измерения эффекта от реализации Плана улучшения услуг. Если базовое состояние не было определено изначально, им становится состояние первого замера при реализации улучшения. Существует четыре причины для измерения и мониторинга: o для проверки - измерение и мониторинг проверяет принятые решения; o для направления - измерение и мониторинг определяют направление дальнейших действий для достижения установленных целей; o для обоснования - измерение и мониторинг позволяют создать обоснование тех или иных действий, построенное на реальных данных; o для вступления - измерение и мониторинг позволяют определить точки, в которых необходимо осуществить коррекцию или изменения. CSI использует процесс из 7 шагов, представленный на рис. 14.5. Рис. 14.5. Процесс Непрерывного улучшения услуг Рассмотрим представленные на рис. 14.5 шаги: o определить то, что необходимо измерить. Эта информация определяется на этапах Построения стратегии и Проектировании услуг. CSI начинает свой цикл от вопроса "Где мы сейчас?" o определить то, что можно измерить. Эти деятельности относятся к вопросу "Где мы хотим быть".CSI находит возможности для улучшения посредством анализа новых требований бизнеса, возможностей IT и доступных финансовых средств. В то же время CSI отвечает на вопрос "Как нам попасть туда?" o сбор данных. Чтобы ответить на вопрос "Мы попали туда?" CSI с помощью этапа Эксплуатации должен собирать данные. o обработка данных. Данные обрабатываются в соответствии с определенными критическими факторами успеха и ключевыми показателями производительности. Ключевой целью данного этапа является объединение данных от разрозненных источников в единое целое и построение целостной картины текущей ситуации. o анализ данных. На этом этапе данные становятся информацией, с помощью которой определяются направления развития услуг, все несовпадения с установленными требованиями и влияние услуг на бизнес. o использование информации. На этом шаге формируется ответ на вопрос "Мы попали туда?". Ответ передается всем заинтересованным лицам и позволяет им сформировать выводы об успешности улучшения. o корректирующие действия. С помощью предыдущих этапов менеджеры находят проблемы и предпринимают действия по их устранению. Описанный процесс является циклическим. После его завершения организация формирует новое базовое состояние, и цикл начинается заново. 7 шагов фактически представляют процесс трансформации данных в опыт. Не стоит путать понятия данные, информация, знания и опыт. Данные определены как числа, буквы, картинки и т.п. Они как бы отображают факты, в то время как информация является структурированными и проанализированными данными. Информация определяется как принятое и понятое сообщение. Это данные о фактах, на основании которых может быть принято решение. Например, Вы говорите только на русском языке, а Вам прислали письмо на китайском. Оно содержит в себе данные, но для Вас они не являются информацией, так как их невозможно понять. Вы можете обратиться к переводчику и прочитать сообщение - то есть данные станут информацией после перевода, то есть обработки и анализа. Знания могут быть определены как информация в совокупности с опытом, интерпретацией и контекстом использования. Опыт представляет собой способность принимать взвешенные решения. Он опирается на использование доступных знаний. 8. Управление знаниями В предыдущих лекциях мы уже рассматривали модель DIKW. В контексте CSI она принимает особое значение. Данные должны собираться на каждом этапе, чтобы затем трансформироваться в знания и опыт, которые позволят CSI быть эффективным в дальнейшем. 9. Зафиксированные состояния Зафиксированное состояние (Benchmark) - состояние чего-либо, зафиксированное на определенный момент времени. Зафиксированное состояние может быть создано для конфигураций, процесса или любого другого набора данных[1]. В контексте CSI оно используется для фиксации текущего состояния и управления улучшениями. Сравнение состояний (Benchmarking) - сравнение зафиксированного состояния с базовым состоянием или с лучшей практикой. Термин сравнение состояний также используется в следующем смысле - создание серии зафиксированных состояний в течении определенного отрезка времени и сравнение полученных результатов для оценки прогресса или улучшения[1]. Сравнение состояний, по сути, является стратегическим процессом. Организации сравнивают различные аспекты своей деятельности с лучшими практиками области, в которой работают, и ищут пути по их применению. Благодаря этому процессу, они формируют оценку состояния качества и производительности своей работы в сравнении с конкурентами и взглядами заказчиков. Если сравнение состояний получает негативный результат на выходе, организации необходимо предпринять действия по улучшению своей деятельности. Результаты сравнения состояний должны четко определить все несоответствия, расхождения и риски, связанные с ними. Сравнение состояний зачастую единственный путь для того, чтобы "открыть" организацию на изменения, использование новых методов и технологий, которые позволят повысить эффективность и результативность деятельности организации. Процесс позволяет разрушить сопротивление изменениям путем демонстрации новых методов решения проблем. Это техника для улучшения производительности организации в целом. Она используется для сравнения производительностей организаций или различных организационных единиц в рамках одной организации. ITIL определяет сравнение состояний как "метод поиска лучших практик области, ведущих в сверхпроизводительности". Лекция 15: Процессы в рамках Непрерывного улучшения услуг Аннотация: Процессы и деятельности в рамках Непрерывного улучшения услуг. В лекции также рассматривается связь Непрерывного улучшения услуг с другими этапами жизненного цикла услуг. Ключевые слова: SLA, список, затраты, CSI, анализ, принятия решений, процесс управления, опыт, информация, ITIL, улучшение, жизненный цикл, service, improvement, очередь, мониторинг, поиск, отображение, сервер, сеть, определение, K PI, понятность, значение, SMART, relevant, RFC, тренд, интервал, ROI, таблица, стоимость, приложе ние, SLM, цикла, sip 15.1. 7-шаговый процесс улучшения Мы уже рассматривали основные шаги этого процесса улучшения в предыдущей лекции. В этой лекции мы рассмотрим его более детально (рис. 15.1). увеличить изображение Рис. 15.1. 7-шаговый процесс улучшения Шаги 1 и 2 циклически повторяются и тесно связаны со стратегическими, тактическими и операционными задачами организации. Для поддержки деятельностей по улучшению, организация может заказать и внедрить новую технологию по сбору и обработке данных или нанять персонал с необходимой квалификацией. Организация часто пренебрегает первыми шагами из-за ряда ошибочных утверждений: • Процесс улучшения не включает эти шаги. На практике часто начинают собирать данные без четкого понимания, что именно должно собираться и зачем. • IT знает лучше, что нужно заказчикам. Это утверждение является ошибочным, так как именно заказчики должны определять, что именно нужно измерять и для чего. Даже при условии наличия SLA в нем могут быть установлены недостижимые требования по измерению и отчетности, что неминуемо приведет к неудовлетворенности заказчиков. • Инструменты измерения достаточно сложны и могут собирать данные в бесконечном множестве точек. Часто IT организации слишком полагаются на автоматизированные устройства сбора данных, ошибочно предполагая, что они достаточно "умны" для того, чтобы корректно определять точки измерения. Рассмотрим 7 шагов процесса улучшения. Шаг 1 - Определить то, что необходимо измерить Шаг 1 представляет собой диалог между поставщиком и заказчиками, который позволит избежать разногласий в будущем. Здесь они договариваются о целях и задачах, в соответствии с которыми решается, что необходимо измерять. Стартовой точкой для обсуждения является Каталог услуг и требования уровня услуг различных заказчиков. Здесь поставщик услуг как бы говорит себе:"Что я бы измерял в идеальном мире? Что наиболее важно для бизнеса?". На данном этапе необходимо объединить цели и задачи организации, цели и задачи IT, критические факторы успеха, требования уровня услуг и должностные инструкции персонала. Шаг 2 - Определить то, что можно измерить На практике всегда есть ограничения относительно того, что действительно можно измерить. Если что-то нельзя измерить, это необходимо исключить из SLA. Необходимо начать с построения списка имеющихся инструментов (инструменты управления услугами, ведения отчетности, мониторинга и др.). Дополнить список тем, что может измерить каждый инструмент без дополнительной кастомизации и настройки. Кастомизация здесь модификация в соответствии с требованиями конкретного заказчика. Кастомизация усложняет процесс и увеличивает затраты, поэтому поставщик услуг должен стремиться ее минимизировать. Шаг три - Сбор данных Сбор данных предполагает наличие установленного механизма мониторинга в рамках организации. Он может быть как автоматическим, так и ручным. В контексте CSI упор в мониторинге должен быть сделан не на актуальном состоянии объектов, а на поиске мест, где требуются улучшения или где они возможны. Для поддержки CSI организация должна собирать значения следующих метрик: • метрики технологий - это такие метрики технологий и компонентов как производительность, доступность и т.п. • метрики процессов - эти данные собираются в форме критических факторов успеха, ключевых показателей эффективности и других метрик процессов в рамках сервис-менеджмента. Они позволяют определить состояние процесса в целом. • метрики услуг - эти метрики отражают результат услуг в целом. Сбор данных должен быть максимально стандартизован с помощью политик, правил и стандартов. При мониторинге особенное внимание следует уделять исключениям и предупреждениям, так как они могут стать предвестниками сбоя работы услуг. Они могут поступать как от автоматических инструментов, так и от людей, которые используют услуги. На рис. 15.2 представлены процедуры в рамках мониторинга. увеличить изображение Рис. 15.2. Мониторинг Шаг 4 - Обработка данных Обработка данных, по сути, трансформирует их в информацию для дальнейшего анализа. На этой стадии формируются отчеты, которые представляют собранные данные в удобном для восприятия виде. На рис. 15.3 изображены основные процедуры обработки данных. увеличить изображение Рис. 15.3. Обработка данных Шаг 5 - Анализ данных Для принятия решений необходимо провести анализ собранных данных и информации. Например, на основе мониторинга установлено, что в организации на 20 процентов снизилось число обращений в сервис-деск. Это может произойти по двум причинам. Первая - процесс Управления проблемами в организации эффективно решает проблемы, и они не появляются в дальнейшем. Вторая - сервис-деск работает неэффективно, и персонал не обращается в него, так как не получает должной поддержки. Если обработка превращает данные в информацию, то анализ превращает информацию в знания, необходимые для принятия взвешенных решений. Соответственно, для анализа данных необходима большая квалификация, чем для их сбора и обработки. В процессе анализа необходимо ответить на такие вопросы как: • эксплуатация услуг проходит в соответствии с планом? Это может быть проектный план, финансовый план, план управления мощностями, доступностью или непрерывностью. • цели, определенные в SLA или Каталоге услуг, достигнуты? • есть ли структурные проблемы? • есть ли необходимость в корректирующих действиях? • можно ли выделить какие-то направления? Они положительные или отрицательные? • что движет направлениями или порождает их? В оригинале используется слово "тренд". Тренд, по сути, и есть направление. В дальнейшем мы будем использовать термины "тренд" и "направление" как синонимы. Выделение направлений является важной задачей этапа анализа. Недостаточно просто получить информацию о состоянии услуг и организации в заданный момент времени, необходимо отслеживать эти состояния и выявлять тенденции их развития. Шаг 6 - Использование и предоставление информации На этом шаге знания трансформируются в опыт посредством их использования и публикации. Информация должна предоставляться целевой аудитории в максимально удобном и понятном для нее виде. Другими словами, информация должна предоставляться так, чтобы быть наиболее полезной. Необходимо четко понимать разницу в целевых аудиториях. Так, отчеты для IT должны отличаться от отчетов для бизнеса, так как их интересует разная информация. Например, IT захочет увидеть процентные показатели доступности услуг, а бизнес - время простоя услуг и влияние простоя на бизнес. Задачей IT является трансформировать информацию в тот вид, который хочет получить бизнес. В ITIL выделено три основные аудитории: • бизнес. Бизнес хочет получить информацию о том, предоставляет ли IT услуги на согласованных уровнях и , если нет, какие действия были предприняты по исправлению ситуации; • высшее руководство IT. Высшее руководство IT интересуют результаты работы в контексте ключевых показателей эффективности и критических факторов успеха. На основе такой информации принимаются стратегические и тактические решения крупного масштаба; • сотрудники IT. IT интересует информация, связанная с непосредственным использованием услуг. Эта информация используется ими для поиска возможностей для улучшения, планирования и координации деятельностей в рамках сервис-менеджмента. Шаг 7 - Реализация корректирующих действий На этом шаге на основе информации, полученной из предыдущих шагов, выявляются проблемы, которые стоят перед IT и бизнесом, и осуществляются действия по их устранению. Другими словами происходит непосредственное улучшение услуг и процессов. После их реализации, жизненный цикл услуг продолжается. Рассмотрим пример из публикации "ITILv3.Continual Service Improvement". Финансовая организация владеет сайтом, который является для нее стратегически важным ресурсом. На основе отчетов было выявлено, что качество услуг, предоставляемых сайтом, не соответствует целевым показателям. Высшее руководство бизнеса обращается к высшему руководству IT с просьбой предпринять действия по исправлению ситуации. IT, в свою очередь, пересматривает отчеты с целью поиска причин возникновения проблем. Выделяются люди для мониторинга конкретной услуги. Они формируют отчеты о производительности услуги с установленной периодичностью. Отдельные люди, ответственные за улучшения, предпринимают корректирующие действия для исправления ситуации. При этом в ITIL подчеркивается необходимость разделения ролей и ответственностей в данном процессе. То есть те, кто осуществляет мониторинг, не должны реализовывать улучшения, и наоборот. Ни один из рассмотренных выше семи шагов не должен быть упущен или недостаточно проработан. Ошибки и недоработки могут привести к неэффективности всего процесса CSI. 15.2. Формирование отчетности При формировании отчетности IT необходимо: • определить цель отчета; • определить целевую аудиторию; • определить для чего будет использован отчет. Значительное количество данных собирается в процессе ежедневной работы, но не все из них являются ценными и могут быть использованы для анализа и принятия решений. Для того чтобы структурировать процесс формирования отчетности необходимо согласовать политику и правила с бизнесом и этапом Проектирования. Они могут включать в себя: • целевую аудиторию; • соглашение о том, что будет измеряться и отражаться в отчетах; • термины и границы; • расписание формирования отчетности; • доступ к отчетам и средства, которые будут использованы для его осуществления; • расписание встреч для обсуждения отчетов. Отчеты должны быть простыми для понимания и в то же время эффективными. Задачей IT является формирование отчетов в терминах, понятных бизнесу. На рис. 15.3 изображен процесс формирования отчетности. Рис. 15.4. Процесс формирования отчетов 15.3. Измерение услуг Под измерением услуг понимается измерение результатов услуг. Измерение услуг бессмысленно без дальнейшей обработки информации и реализации действий по улучшению. Информация, получающаяся в результате измерения, служит для трех основных целей: информирования о состоянии услуг заинтересованных сторон, сравнение с целевыми показателями, поисквозможностей для улучшений. Для измерения услуг, как уже отмечалось в предыдущих лекциях, большинство организаций используют три показателя: • доступность услуг; • надежность услуг; • производительность услуг. Задачей измерения услуг является отображение объективной информации о предоставлении услуг. При этом IT не должно формально относиться к данному процессу. Например, сервер исправно работает, но сеть недоступна - услуга, предоставляемая сервером, недоступна для пользователей. Поэтому помимо услуг необходимо отслеживать работу компонентов, приложений, систем и процессов, которые их поддерживают. При этом уровень измерения услуг стоит выше измерения отдельных составляющих услуг. На рис. 15.5 показаны различные уровни, на которых может быть осуществлено измерение доступности. увеличить изображение Рис. 15.5. Измерение доступности Основой измерения услуг является Система измерения услуг. Для ее построения IT необходимо понимание бизнес-процессов и определение того, что наиболее критично в предоставлении бизнесу ценности. Цели и задачи IT должны соответствовать целям и задачам бизнеса и поддерживать их. Измерение услуг не предназначено для того, чтобы смотреть в прошлое. Оно предназначено в первую очередь для ответа на вопросы "что мы можем сделать" и "как нам сделать это лучше". Выходы процесса измерения услуг должны позволить менеджменту принимать взвешенные операционные, тактические и стратегические решения. Для построения Системы измерения услуг необходимо определить, что именно будет измеряться: • услуги; • компоненты; • процессы сервис-менеджмента, которые поддерживают услуги; • деятельности в рамках процессов; • результаты. Для измерения необходимо четко понимать "как будет выглядеть успех", то есть "чего мы хотим достигнуть" и "как мы можем сделать это". В рамках построения Системы измерения услуг отвечают на следующие вопросы: • что нам нужно измерить, чтобы получить полезную для принятия решений информацию? • какие средства предоставят нам требуемые данные и информацию? • какие целевые показатели будут использоваться? Чаще всего используется Соглашение об уровне услуг (SLA). • кто будет определять средства измерения и целевые показатели? • кто будет осуществлять мониторинг и измерение? • кто будет управлять данными? • кто будет обрабатывать и анализировать данные? • кто будет подготавливать отчеты? • кто будет представлять отчеты? Система измерения услуг предназначена для объединения различных мер и метрик. Конечным результатом является формирование общего взгляда на услуги в контексте измерения их компонентов. Эта информация станет основой для построения оценочной ведомости услуг и формирования системы сбалансированных показателей. Оценочная ведомость услуг является своего рода карточкой состояния услуги за определенный промежуток времени - недели, месяца, квартала. Система сбалансированных показателей (Balanced Scorecard) - инструмент управления, разработанный докторами Робертом Капланом (Гарвадская бизнес-школа, Harvard Business School) и Дэвидом Нортоном. Система сбалансированных показателей позволяет декомпозировать Стратегию до Ключевых показателей производительности (KPI). Соотнесение Производительности с KPIиспользуется для демонстрации успешности исполнения Стратегии. Сбалансированный показатель состоит из 4-х главных блоков (областей, направлений), каждый из которых включает в себя небольшое количество KPI[1]. На рис. 15.6 представлены различные уровни, которые должны быть рассмотрены в рамках построения Системы измерения услуг. увеличить изображение Рис. 15.6. Система измерения услуг Что будет измеряться на каждом отдельном уровне зависит от выбранных систем измерения. На самом низшем уровне измеряются показатели доступности, надежности и производительности отдельных компонентов. Результаты измерения являются основой для построения Планов обеспечения непрерывности и доступности и измерения услуги в целом. Эффективное измерение услуг должно быть сконцентрировано вокруг нескольких важных индикаторов, которые будут полезны для достижения желаемых результатов. Если таких индикаторов будет много, процесс измерения потеряет эффективность, понятность и лаконичность. На уровне измерения услуг IT должно представлять результаты в понятном для бизнеса виде. ITIL не рекомендует использовать процентные показатели доступности, надежности и производительности. Они используются на уровне отдельных компонентов. Ниже приведены показатели, которые имеют значение для заказчиков: • количество сбоев каждой услуги. Например, 2 сбоя услуги 1 в течение месяца; • продолжительность простоя каждой услуги. Например, сбои услуги 1 длились 3 часа; • влияние простоя на бизнес. Например, бизнес использует 10 услуг, общее количество сбоев за месяц - 13, общая продолжительность простоя - 1800 минут. То есть бизнес в течение 1800 минут не получал прибыль. При определении метрик и мер, которые будут использоваться, необходимо учитывать ограничения, то есть находить ответ на вопрос "что мы можем измерить". После определения мер, необходимо установить целевые показатели. Целевые показатели являются количественным отображением целей, которые должны быть достигнуты. Обычно они определяются исходя из требований бизнеса или требований регуляторов и включаются в SLA. При определении целевых показателей необходимо учитывать фактические возможности IT. ITIL рекомендует применять пофазовый подход, который заключается в том, что для первой фазы целевые показатели будут ниже, чем для второй, и т.д. Целевые показатели должны удовлетворять принципу SMART (specific - индивидуальный, measurable - измеряемый, achievable достижимый, relevant - значимый, timely - своевременный). Они должны быть достижимы и понятны для тех, кто будет с ними работать. Определение целевых показателей является стартовой точкой для построения базового состояния, с помощью которого в дальнейшем будет измерена эффективность улучшения. Для измерения процессов сервис-менеджмента применяется такой же подход. На уровне деятельностей процесса определяется то, что будет измеряться на основе ключевых показателей производительности (KPI). KPI в свою очередь должны поддерживать цели высокого уровня. Рассмотрим пример из публикации "ITILv3. Continual Service Improvement". Процесс Управленияизменениями предназначен для повышения качества услуг. Одна из основных проблем с качеством услуг - простой услуг в результате неудавшихся изменений. Основная причина неудавшихся изменений - большое количество срочных изменений, которые проводятся в обход формального процесса реализации изменений. В этом контексте предлагаются следующие метрики деятельности: • количество срочных изменений; • количество неудавшихся срочных изменений; • неавторизованные неудавшиеся изменения. Четыре главных уровня для ведения отчетности. Нижний уровень содержит метрики деятельностей процесса, например, количество утвержденных Запросов на изменение (RFC) или количество успешно реализованных изменений. Следующий уровень содержит ключевые показатели производительности для каждого процесса. Метрики деятельностей процесса должны поддерживать KPI. KPI в свою очередь поддерживают цели высокого уровня, например, повышение качества услуг, уменьшение затрат или увеличение удовлетворенности пользователей. В итоге все попадает в Систему сбалансированных показателей (рисунок 15.7). Рис. 15.7. Модель сервис-менеджмента ITIL рекомендует создать некий фильтр для KPI, который будет определять, какие именно KPI поддерживают цели высокого уровня. В табл. 15.1 приведен пример цели высокого уровня и поддерживающих ее KPI. Таблица 15.1. Цель высокого KPI Категория KPI Измерение уровня Управление Процентное Качество Итоговая доступностью улучшение доступность и надежностью итоговой измеряется услуг доступности исходя из услуг доступности отдельных компонентов услуг Можно выделить следующие категории KPI: • соответствие - мы делаем это? • качество - как хорошо мы делаем это? • производительность - быстро или медленно мы делаем это? • ценность - то, что мы делаем, изменяет ситуацию? Целевой показатель 99,3% Как и кто Технические менеджеры Технические Аналитики Менеджеры уровня услуг Следующим этапом является обработка полученных в результате измерения данных. Если выявляется негативный тренд, необходимо понять, были ли сделаны какие-то изменения в заданный интервал времени и как они повлияли на услуги и процессы. Система измерения должна стать опорой для принятия стратегических, тактических и операционных решений. Возможности для улучшений есть всегда, но доступные средства при этом ограничены. Руководству приходится выбирать и отвечать на вопросы - какие улучшения лучше поддержат цели и задачи бизнеса? Какой ROI и VOI? Другой точкой применения является сравнение. Результаты измерения могут нести в себе мало смысла без последующего сравнения со стандартом или базовым состоянием. Используются следующие сравнения: • сравнение с базовым состоянием; • сравнение с целями или задачами; • сравнение с SLA; • сравнение с другими организациями; • сравнение в рамках разных временных интервалов - по дням, неделям, месяцам, кварталам; • сравнение между разными бизнес-единицами; • сравнение между услугами; • сравнение со стандартами. Временное или незначительное расхождение с целевыми показателями не всегда порождает необходимость улучшений. Поэтому прежде чем приступать к реализации программы улучшения необходимо ввести пороговые значения расхождений. На основе результатов сравнения создаются отчеты. Они создаются для : • отображения результатов работы услуг; • отображения состояния процессов сервис-менеджмента; • функциональные отчеты (например, отчет о количестве звонков в сервис-деск). Перед тем, как приступить к созданию отчетов, необходимо ответить на ряд вопросов: • какая целевая аудитория этого отчета? • для чего будет использован отчет? • кто ответственен за создание отчета? • как будет создаваться отчет? • как часто будет создаваться отчет? Многое зависит от целевой аудитории отчета. Например, высшее руководство не хочет знать технические подробности и читать длинные отчеты. Они предпочтут увидеть результат работы за, например, месяц в лаконичном виде - 1-2 листа по рекомендациям ITIL. Также важно учитывать формат отчета, который предпочитает целевая аудитория - это могут быть графики и диаграммы, текстовый отчет, таблица, веб-отчет и т.п. 15.4. ROI для Непрерывного улучшения услуг Многие организации хотят понять стоимость улучшений и усилия, которые необходимо предпринять для их реализации. Эти значения должны сравниваться с выгодами, которые получит организация от улучшений. Выгоды посчитать гораздо труднее, чем издержки. Чтобы сравнивать затраты на улучшения и его результаты необходимо знать следующее: • Какова стоимость простоя? Сюда входит потеря производительности, прибыли и покупателей. • Какова стоимость повторного выполнения работ? Как много неудавшихся изменений должны быть отменены и повторно выполнены? • Какова стоимость излишней работы? Организации с нечеткими процессами и плохой связью между ними вынужденно выполняют много лишней/дублирующей работы. • Какова стоимость проектов, которые не принесли ценности? Многие проекты, которые были полностью профинансированы и выполнены, в конечном итоге не принесли организации ценности, например, ввиду изменения требований. • Какова стоимость задержки в предоставлении приложений? Влияет ли она на способность предоставления новых услуг? • Какова стоимость передачи инцидентов на вторую и третью ступень поддержки в сравнении с их разрешением на первой ступени? • Какова средняя стоимость часа работы для сотрудников? Выше перечислены только основные вопросы, которые необходимо рассмотреть в рамках анализа ROI. Существует множество методов измерения доступности и ведения соответствующих отчетов: 1. влияние потерянных минут - время простоя, умноженное на количество пользователей, на которых он повлиял. Пользователи в период простоя теряют свою производительность, так как не могут выполнять работу. 2. влияние на бизнес-транзакции - количество бизнес-транзакций, которые не могут быть завершены из-за простоя; 3. реальные издержки от простоя. Можно разбить влияние на пользователей по компонентам (табл. 15.2). Таблица 15.2. Компонент Количество затронутых пользователей Центральный блок обработки данных28,547 Центральный маршрутизатор 17,433 Приложение XYZ 7, 354 База данных ABC 1,819 Единичная рабочая станция 1 При сбое необходимо определить продолжительность простоя, количество людей, которых он затронул, и, с помощью стоимости часа работы, посчитать издержки в результате потери производительности. Например, приложение из табл. 15.2 вышло из строя и это негативно отразилось на 7 354 пользователях. Время простоя составило 39 минут. Средняя стоимость часа работы 100 рублей. Тогда количество пользователей умножаем на 39 минут, и делим на 60 (переводим в часы) и все это умножаем на стоимость часа (100 рублей). Получаем стоимость простоя -(7354*39/60)*100=478010 рублей. Подсчет стоимости простоя является ключевым для определения потерь бизнеса в случае недоступности услуги. На следующем шаге необходимо посчитать стоимость улучшений, которые необходимо реализовать для повышения доступности услуги. Метод подсчета должен выбираться в зависимости от сущности операций и процессов бизнеса. Допустим, организация точно знает стоимость простоя. Обычно она изменяется в зависимости от типа предоставляемой услуги. В табл. 15.3 приведены три типа услуг и стоимость часа простоя каждого из них. Таблица 15.3. Тип услуги Стоимость часа простоя (рублей) Особо критичные услуги200 000 Критичные услуги 90 000 Не критичные услуги 11 500 Допустим, на улучшение услуг потрачено 300 000 рублей (табл. 15.4). Таблица 15.4. Информация об инвестициях Инвестиции на улучшение с целью уменьшения времени простоя услуг Количество предотвращенных минут простоя, которые оправдают инвестиции Особо критичные услуги Критичные услуги Не критичные услуги Инвестиции 300 000 рублей Возврат в минутах 90 минут 200 минут 1556 минут Инвестиции вернутся быстро для первых двух типов услуг, так как стоимость простоя у них выше. Если бизнес и IT не могут прийти к соглашению о стоимости часа простоя или потери производительности работы сотрудников, применяется другой метод. Например, можно разделить годовую стоимость предоставления услуги на количество часов, которые она работает в году. Полученная величина отобразит, сколько тратит бизнес на каждый час работы услуги. При построении обоснования необходимости улучшения - бизнес-кейса - нужно также учитывать нематериальные выгоды. То есть нельзя ограничиваться только подсчетом ROI, нужно использовать VOI. ROI не может посчитать все выгоды, которые получит бизнес от реализации улучшения. После того, как улучшение реализовано, необходимо измерить его результаты, то есть полученные выгоды. Естественно, на практике они не всегда совпадают с теми, которые были запланированы при построении бизнес-кейса. Ниже приведены вопросы, которые могут помочь процессу оценки успешности улучшения: • были ли реализованы все предусмотренные улучшения? • были ли получены выгоды от улучшений? • было ли достигнуто целевое значение ROI? • было ли достигнуто запланированное увеличение ценности (VOI)? • свидетельствуют ли полученные результаты о необходимости повторных действий по улучшению? • достаточно ли прошло времени для того, чтобы измерять выгоды? Не все выгоды от улучшений проявляются и появляются сразу. Данные, на основе которых строилась оценка до реализации улучшения, могут отличаться от тех, которые появились после реализации. Поэтому прежде чем оценивать результаты улучшения необходимо структурировать и привести в соответствие данные "до и после". 15.5. Вопросы бизнеса к CSI Бизнес принимает решения относительно того, какие инициативы по улучшению принесут пользу работе и могут быть профинансированы. ITIL устанавливает перечень вопросов, которые могут помочь бизнесу в принятии таких решений: • Где мы сейчас? С этого вопроса бизнес должен начинать любой процесс по оценке инициативы улучшения. Ответ на этот вопрос даст основу для построения базового состояния услуг, которые предоставляются на текущий момент времени. Базовое состояние придает значение будущим измерениям, так как является точкой сравнения того, что было, с тем, что получилось в итоге. • Что мы хотим? Ответ обычно заключается в требованиях бизнеса, например, 100 % доступность услуг или неограниченная мощность. При этом важно также установить причины этих требований, например, удовлетворенность потребителей или конкурентное преимущество. Так, отдел продаж может хотеть увеличить доступность веб-услуг на 25 % и тем самым увеличить удовлетворенность покупателей, увеличить вероятность продаж и конкурентное преимущество. • Что нам на самом деле нужно? В рамках обсуждения SLA бизнес может понять, что на самом деле ему не нужна 100% доступность услуг. • Что мы можем позволить себе? Возможности бизнеса ограничены и не всегда он может позволить себе всё, что хочет. Бизнес должен в первую очередь исходить из своих финансовых возможностей. Именно на этом этапе чаще всего происходит переоценка "то, что мы хотим" в "то, что нам действительно нужно". Например, организация хочет увеличить доступность услуги с 98% на 99%. Но это стоит 3000 000 рублей. Стоит ли 1 % увеличения доступности этих денег? Может ли бизнес позволить себе такие траты? Действительно ли данная услуга критична? • Что мы получим? Ответ на этот вопрос заключается в SLA в виде целевых показателей и согласованных уровнях услуг. • Что мы получили? Ответ на тот вопрос находится в результатах мониторинга, отчетах, обзорах о работе услуг. На рис. 15.8 схематически изображен подход бизнеса к улучшению. увеличить изображение Рис. 15.8. Улучшения с точки зрения бизнеса 15.6. Управление уровнем услуг (SLM) В предыдущих лекциях мы уже не раз говорили об этом процессе, тем не менее, вспомним его определение еще раз. Управление уровнем услуг (Service Level Management) - процесс, ответственный за обсуждение Соглашений об уровне услуг, и гарантирующий их выполнение. SLM ответственен за то, что процессы Управления услугами, соглашения операционного уровня и внешние договоры будут соответствовать согласованным целевым показателям уровня услуги. SLM отслеживает и отчитывается по уровням услуг, выполняет регулярные обзоры для Заказчиков[1]. SLM помогает CSI тем, что определяет требования к мониторингу и объекты мониторинга - то, что необходимо контролировать. С помощью SLM бизнес "доносит" до IT свои желания, потребности и новые требования к услугам. Это дает старт CSI и помогает ранжировать проекты и инициативы по улучшению. SLM создается на этапе Проектирования жизненного цикла услуг. CSI должен принимать участие в создании SLM, чтобы в нем были определены достижимые цели, от которых будут определяться возможности для улучшения услуг. SLM, в свою очередь, является триггером для создания Плана улучшения услуг (SIP). IT и бизнес следят за тем, чтобы SLM выполнялся, и услуги предоставлялись на согласованных уровнях. В случае появления несоответствий, возникает необходимость в улучшениях. Заключение и словарь К сожалению, мода на ITIL последние 15 лет привела к тому, что многие организации внедряют ITIL без четкой цели. Внедрение ITIL требует колоссальных затрат, которые не окупятся при отсутствии понимания и рационального подхода. Не каждая организация может позволить себе внедрить все процессы ITIL, а зачастую в этом нет необходимости. Тем не менее, отдельные процессы и функции ITIL нашли широкое применение в российских компаниях: сервис-деск, управление инцидентами, управление проблемами и управление конфигурациями. ITIL третьей версии кардинально меняет подход к предоставлению услуг, предлагая IT ориентироваться на требования и возможности бизнеса. Публикации ITIL о том, "как должно быть", не зря библиотеку называют "набором лучших практик". При этом ITIL концентрируется на результатах предоставления услуг, а не технологиях, используемых для формирования этих результатов. Процессы, описанные в ITIL, в том или ином виде существуют в любой организации, связанной с IT. Использование ITIL предполагает их структурирование и стандартизацию предоставления услуг и управления ими, что дает возможность представителям IT и бизнеса говорить на одном языке. Аудиторы, специалисты других организаций, поставщики и партнеры смогут легко понять Вас, если Вы используете терминологию ITIL. Управление услугами(Service Management) это множество специализированных организационных возможностей для предоставления ценности заказчикам в форме услуг. Заказчик(Customer) - это покупатель товаров или услуг. Заказчик для поставщика IT-услуг - это человек (группа людей), который заключает соглашения с поставщиком на предоставление ITуслуг и отвечает за то, чтобы предоставленные услуги были оплачены. Поставщик услуг(Service provider) - это организация, поставляющая услуги одному или нескольким внутренним или внешним заказчикам. Пользователь - это сотрудник организации, использующий IT-услугу для выполнения повседневной работы. IT-услуга (сервис) - способ предоставления ценности заказчикам через содействие им в получении результатов на выходе, которых заказчики хотят достичь без владения специфическими затратами и рисками определённых потребностей. Зачастую определяется как "что делает продукт/сервис". Полезность услуги - функциональность IT-услуги с точки зрения заказчика. Гарантия - обещание или гарантия того, что продукт или услуга будет соответствовать согласованным требованиям. Гарантия качества услуги - уверенность в том, что IT-сервис будет соответствовать согласованным требованиям. Может быть в виде формального соглашения, такого как SLA или договор, либо как маркетинговое сообщение или представление торговой марки. Производительность (Performance) - мера того, что достигнуто или выработано системой, человеком, командой, процессом, или ИТ-услугой. Ограничение - это запрет или невозможность выполнения каких-то действий. Организация - это определенная форма сотрудничества людей. Миссия - это короткое и четкое описание задач, стоящих перед организацией, и идеалов, в которые она верит. Стратегические задачи (objectives) - это более подробное описание того, что хочет достичь организация в долгосрочной перспективе. Политика организации (policy) - это совокупность всех решений и мер, принятых организацией для постановки стратегических задач и их достижения. Критические факторы успеха (Critical Success Factors или CSFs) - факторы, которые обязательно должны реализовываться для успешности проекта, процесса, плана или услуги. Такие факторы формулируются для нескольких наиболее важных сфер интересов компании, называемых перспективами (проекциями) организации: заказчики/рынок, бизнес-процессы, персонал/инновации и финансы. Для измерения того, насколько успешно реализованы CSFs используется KPI. Ключевой показатель производительности (Key Performance Indicator или KPI) метрика, которая используется для управления процессом, услугой или деятельностью. Портфель услуг- это полный набор услуг, которые предоставляются поставщиком услуг. Портфель услуг используется для управления всеми услугами на протяжении всего их жизненного цикла и включает три категории: 1) услуги в разработке (ServicePipeline) - услуги, находящиеся в стадии разработки; 2) каталог услуг для уже используемых или предлагаемых услуг и 3) услуг, выведенных из эксплуатации (retired Services). Проектная документация услуги (Service Design Package или SDP) - документы, определяющие все аспекты услуги и требования к ней на каждой стадии жизненного цикла. Пакет уровней услуг (Service Level Package или SLP) - это определенный уровень полезности и гарантии для отдельного пакета услуг. Система управления знаниями по услугам (Service Knowledge Management System или SKMS) - набор инструментов и баз данных, которые используются для систематизации знаний и информации об услуге. Она сохраняет, управляет, обновляет и предоставляет всю информацию, которая необходима поставщику для управления услугой на всех этапах жизненного цикла. Функции (Functions) - части организации, специализированные для того, чтобы выполнять определенные виды работ и отвечать за формирование соответствующих результатов. Функции обладают всеми необходимыми для выполнения работы возможностями и ресурсами. Возможности включают в себя собственные методы работы и накопленный опыт. Функции обеспечивают структурированность и стабильность организации. Процесс - структурированный набор видов деятельности, спроектированный для достижения определенной цели. Процесс может включать в себя роли, ответственность, инструментарий и методы контроля, необходимые для формирования результатов. Активность или деятельность (Activity) - набор действий, спроектированный с целью получения определенного результата. Активности обычно определяются как части процессов или планов, и документируются в процедурах. Бизнес-единица (business unit или BU) - сегмент бизнеса, который имеет свои собственные метрики, планы, доходы и расходы. Каждая бизнес-единица владеет и управляет активами, которые использует для создания товаров и услуг с определенной ценностью. Система управления конфигурацией (Configuration Management System или CMS) набор инструментов и баз данных, которые используются поставщиком услуг для управления данными о конфигурациях. Управление портфелем услуг (Service Portfolio Management или SPM) - процесс, ответственный за управление Портфелем услуг. Управление портфелем услуг рассматривает Услуги в терминах предоставляемой ценности для бизнеса. Каталог услуг(Service Catalogue) база данных или структурированный документ, содержащий информацию обо всех услугах в режиме промышленной эксплуатации, включая те услуги, которые доступны для развертывания. Управление финансами(Financial Management) - функция и процессы, ответственные за управление бюджетом, учет и возмещение затрат поставщика услуг. Управление мощностями (Capacity Management) - процесс, отвечающий за своевременное и эффективное по затратам соответствие мощности услуг и IT-инфраструктуры требованиям согласованных Целевых показателей уровня услуги. Управление мощностями принимает во внимание все ресурсы, необходимые для предоставления услуг, а также производит краткосрочное, среднесрочное и долгосрочное планирование требований бизнеса. Совокупная стоимость использования (Total Cost of Utilization или TCU) полные затраты заказчика на использование услуги на протяжении всего ее жизненного цикла. Учет затрат (Accounting) - процесс, отвечающий за идентификацию фактических затрат на предоставление ИТ-Услуги, их сопоставление с плановыми затратами, и управление отклонениями от Бюджета. Соответствие (compliance) - обеспечение уверенности в соблюдении стандартов или набора руководящих документов, полноте и целостности чего-либо, использовании определенных установленных правил. Моделирование переменных затрат (Variable Cost Dynamics или VCD) - техника, используемая для понимания, каким образом полные затраты подвергаются влиянию множества комплексных изменяющихся элементов (переменных), вносящих каждый свой вклад в предоставление услуг. Требование к уровню услуг (Service Level Requirements или SLR) - требование заказчика к IT-услуге. SLR(ы) базируются на бизнес-целях и используются для переговоров и согласования Целевых показателей уровня услуги. План обеспечения мощностей(Capacity Plan) используется для управления Ресурсами, необходимыми для предоставления IT-услуг. Этот план содержит сценарии для прогнозирования спроса со стороны бизнеса, и оценку затрат, необходимых для обеспечения согласованных Целевых показателей уровня услуги. Управление поставщиками (Supplier Management) процесс, ответственный за обеспечение того, что договоры с поставщиками соответствуют требованиям бизнеса, и все поставщики выполняют свои контрактные обязательства. Транзакция (Transaction) - дискретная функция, выполняемая ИТ-услугой. Например, перевод денег с одного банковского счета на другой. Одна Транзакция может содержать многочисленные добавления, удаления и изменения данных. при этом все они должны быть завершены успешно, в противном случае ни одна из них не должна быть выполнена (т.е. вся транзакция будет отменена). Инсорсинг (Insourcing) - использование внутреннего поставщика услуг для управления ИТуслугами. Аутсорсинг (Outsourcing) - использование внешнего поставщика услуг для управления ИТуслугами Поставщик услуг прикладного ПО (Application Service Provider или ASP) - внешний поставщик услуг, который предоставляет услуги с использованием приложений, развернутых на мощностях провайдера. Пользователи получают доступ к приложениям посредством сетевого подключения к провайдеру. Конфигурационная единица (Configuration Item или CI) - любой компонент, который нуждается в управлении для того, чтобы предоставлять услугу. Ключевой показатель производительности (Key Performance Indicator или KPI) метрика, которая используется для управления процессом, услугой или деятельностью. Управление уровнем услуг (Service Level Management или SLM) - процесс, ответственный за обсуждение Соглашений об уровне услуг, и гарантирующий их выполнение. SLM ответственен за то, что процессы Управления услугами, соглашения операционного уровня и внешние договоры будут соответствовать согласованным целевым показателям уровня услуги. SLMотслеживает и отчитывается по Уровням услуг, выполняет регулярные обзоры для заказчиков. План совершенствования услуг (Service Improvement plan) - формальный План для внедрения улучшений в процесс или услугу. Обзор результатов внедрения (Post Implementation Review или PIR) - обзор, выполняемый после внедрения изменения или проекта. Он определяет успешность изменения или проекта и выявляет возможности для улучшения. Соглашение операционного уровня (Operational Level Agreement или OLA) - cоглашение между поставщиком услуг и другой частью той же организации. OLA поддерживает поставщика услуг в предоставлении услуг заказчикам. OLA определяет предоставляемые товары или услуги и ответственность обеих сторон. Управление мощностями (Capacity Management) - процесс, отвечающий за своевременное и эффективное по затратам соответствие мощности услуг и инфраструктуры требованиям согласованных целевых показателей уровня услуги. Управление мощностями принимает во внимание все ресурсы, необходимые для предоставления услуг, а также производит краткосрочное, среднесрочное и долгосрочное планирование бизнестребований. Мощность(Capacity) - максимальная пропускная способность, которую может обеспечить конфигурационная единица или услуга в рамках согласованных целевых показателей уровня услуги. Для некоторых типов конфигурационных единиц, мощность может быть выражена размером или объемом, например, жесткого диска. Система управления мощностями (Capacity Management Information System или CMIS) виртуальное хранилище для всех данных в рамках Управления мощностями, обычно имеет физически распределенную архитектуру. Доступность (Availability) - способность конфигурационной единицы или услуги выполнять согласованную функцию, когда это требуется. Доступность определяется через надежность, сопровождаемость, обслуживаемость, производительность и безопасность. Управление доступностью(Availability Management) - процесс, отвечающий за определение, анализ, планирование, измерение и улучшение всех аспектов доступности услуги. Управление доступностью отвечает за то, чтобы вся инфраструктура, процессы, средства, роли и т.д. соответствовали согласованным Целевым показателям уровня услуги в части Доступности. План управления доступностью(Availability Plan) - план, обеспечивающий эффективное по затратам выполнение текущих и будущих требований доступности к услуге. Надежность (Reliability) - мера того, как долго услуга, компонент или конфигурационная единица может выполнять согласованную функцию без прерывания. Среднее время между инцидентами (Mean Time Between Service Incidents или MTBSI) это среднее время от момента сбоя системы или услуги до следующего сбоя. Среднее время между сбоями (Mean Time Between Failures или MTBF)- это среднее время, за которое конфигурационная единица или услуга может выполнять свои функции без перерыва. Измеряется от начала работы до момента следующего сбоя. Среднее время восстановления услуги (Mean Time to Restore Service или MTRS) - среднее время, требуемое для восстановления конфигурационной единицы или услуги после сбоя. MTRS измеряется от момента сбоя конфигурационной единицы или услуги до момента полного восстановления и возврата к нормальной функциональности. Критичная бизнес-функция (Vital Business Function или VBF) - функция в бизнес-процессе, критичная для успеха Бизнеса. Сопровождаемость (Maintainability) - мера быстроты и эффективности восстановления нормальной работы конфигурационной единицы или услуги после сбоя. Обслуживаемость (Serviceability) - способность поставщика третьей стороны выполнить условия договора. Этот договор будет включать в себя согласованные уровни надежности, сопровождаемости или доступности для конфигурационной единицы. Ожидаемый простой услуги (Projected Service Outage или PSO) - документ, определяющий влияние спланированных изменений, деятельности по обслуживанию и планов тестирования на согласованный Уровень услуг. Управление непрерывностью услуг(IT Service Continuity Management или ITSCM) процесс, ответственный за управление рисками, которые влияют на услуги. ITSCM обеспечивает возможность поставщику услуг постоянно предоставлять минимально согласованный Уровень услуг, через снижение рисков до приемлемого уровня и Планирование восстановления услуг. Управление непрерывностью бизнеса (Business Continuity Management или BCM) бизнес-процесс, отвечающий за управление рисками, которые могут серьезно повлиять на бизнес. BCM защищает интересы ключевых заинтересованных сторон, репутацию, бренд и деятельность по созданию ценности. Процесс BCM включает в себя снижение рисков до приемлемого уровня и планирование способов восстановления бизнес-процессов в случае нарушения бизнеса. BCM устанавливает цели, охват и требования по отношению к Управлению непрерывности ИТ-услуг. План обеспечения непрерывности услуг (IT Service Continuity Plan) - план, определяющий шаги, необходимые для восстановления одной или нескольких услуг. План обеспечения непрерывности бизнеса (BusinessмContinuity Plan или BCP) - план определяет шаги, необходимые для восстановления бизнес-процессов в случае нарушения их функционирования. План также должен содержать информацию о событиях, которые являются основанием для его инициирования; людях, которые должны быть задействованы в реализации плана; средствах коммуникаций и т.п. Анализ влияния на бизнес (Business Impact Analysis или BIA) - деятельность в рамках процесса Управлении непрерывностью бизнеса, которая определяет критичные бизнес-функции и их зависимость от факторов окружения. Этими факторами могут быть поставщики, люди, другие бизнес-процессы, услуги и т.д. Оценка рисков (Risk Assessment) - начальные шаги Управления рисками. Анализируется ценность активов для бизнеса, идентифицируются угрозы по отношению к этим активам, и оценивается уязвимость активов по отношению к этим угрозам. Постепенное восстановление (Gradual Recovery) - способ восстановления, также известный как "холодное резервирование". Предусматривается восстановление услуги в течение более чем 72 часов. При постепенном восстановлении обычно задействован мобильный или стационарный резервный центр, оснащенный элементами жизнеобеспечения и сетевой разводкой, без компьютерных систем. Промежуточное восстановление (Intermediate Recovery) - способ восстановления, также известный как "теплое резервирование". Предусматривается восстановление услуги в течение 24 72 часов. При промежуточном восстановлении обычно используется общий мобильный или стационарный резервный центр, оснащенный компьютерными системами и сетевыми компонентами. Конфигурирование аппаратного и программного обеспечения, а также восстановление данных выполняются в рамках Плана обеспечения непрерывности услуг. Быстрое восстановление (Fast Recovery) - способ восстановления, также известный как "горячее резервирование". Предусматривается восстановление услуги за короткий промежуток времени, обычно менее 24 часов. При быстром восстановлении обычно используется выделенный стационарный резервный центр с компьютерными системами и ПО, сконфигурированными для работы услуг. Немедленное восстановление может занимать до 24 часов, если требуется восстановление данных резервного копирования. Немедленное восстановление (Immediate recovery) - способ восстановления, также известный как "горячее резервирование". Предусматривается восстановление услуги без прерывания услуги. Немедленное восстановление обычно использует технологии зеркалирования, балансировки загрузки и разделения площадок установки оборудования. Антикризисное управление (Crisis Management) - процесс, отвечающий за управление непрерывностью бизнеса в самом широком смысле. Команда антикризисного управления отвечает за стратегические вопросы, такие как управление взаимодействием со средствами массовой информации и доверием акционеров, а также принимает решение об инициации планов обеспечения непрерывности бизнеса. Политика информационной безопасности (Security Policy) - система политик, процессов, стандартов, руководящих документов и средств, которые обеспечивают организации достижение целей Управления информационной безопасностью. Система управления информационной безопасностью (Information Security Management System или ISMS) - система политик, процессов, стандартов, руководящих документов и средств, которые обеспечивают организации достижение целей управления информационной безопасностью. Управление поставщиками (Supplier Management) - процесс, ответственный за обеспечение того, что договоры с поставщиками соответствуют требованиям бизнеса, и все поставщики выполняют свои контрактные обязательства. Поставщик (Supplier) - третья сторона, ответственная за поставку товаров или услуг, необходимых для предоставления ИТ-услуг. Примеры поставщиков: вендоры программного и аппаратного обеспечения, сетевые телекоммуникационные провайдеры, а также аутсорсинговые организации. База поставщиков и договоров (Supplier and Contract Database или SCD) - база данных или структурированный документ, используемый для управления договорами поставщиков на протяжении всего их жизненного цикла. SCD содержит ключевые атрибуты всех договоров с поставщиками. Преобразование(Transition) - изменение в состоянии, соответствующее перемещению услуги или конфигурационной единицы из одной стадии жизненного цикла к следующей стадии. Релиз (Release) - набор аппаратного обеспечения, программного обеспечения, документации, процессов или других компонентов, которые необходимы для внедрения одного или нескольких согласованных изменений в услугах. Содержание каждого релиза управляется, тестируется и развертывается как отдельная сущность. Запрос на изменение (Request for Change или RFC) - формальное предложение на реализацию Изменения. RFC включает в себя детальное описание предложенного изменения, и может быть записано в бумажном или электронном формате. Тестирование (Test) - деятельность, которая верифицирует, что конфигурационная единица, услуга, процесс, и т.п., соответствует спецификации или согласованным требованиям. Сборка(Build) - деятельность по компоновке нескольких и более конфигурационных единиц для формирования части услуги. Термин Сборка также используется в отношении релиза, который утвержден для распространения. Например, Сборка сервера или Сборка Ноутбука. Развертывание(Deployment) - деятельность, отвечающая за перемещение нового или измененного оборудования, ПО, документации, процесса, и т.п., в среду промышленной эксплуатации. Поддержка в начале эксплуатации (Early Life Support) - поддержка, предоставляемая в отношении новой или измененной услуги в течение некоторого времени непосредственно после того, как услуга была введена в эксплуатацию. Во время Поддержки в начале эксплуатации поставщик услуг может пересматривать KPI, уровни услуги и наблюдаемые пороговые значения, а также задействовать дополнительные ресурсы для Управления инцидентами и Управления проблемами. Среда (Environment) - подмножество ИТ-инфраструктуры, которое используется в различных целях.. Для сложных Сред есть возможность совместно использовать конфигурационные единицы, например Среды Тестовой и Промышленной эксплуатации могут использовать различные разделы на одном майнфрейме. Также используется в термине физической среды для обозначения помещения, кондиционирования, системы питания и т.п. Среда промышленной эксплуатации (Live Environment) - управляемая среда, содержащая конфигурационные единицы в режиме промышленной эксплуатации, используемые для предоставления услуг. Среда тестирования (Test Environment ) - контролируемая среда, используемая для тестирования конфигурационных единиц, сборок, услуг, Процессов и т.п. Среда сборки (Build Environment) - контролируемая среда, в которой собираются (компонуются) приложения, услуги и другие сборки перед их передачей в Среду тестирования или Среду промышленной эксплуатации. Приемка(Acceptance) - формальное соглашение, определяющее, что услуга, процесс, План или другой результат завершен, является правильным, надежным и отвечает установленным требованиям. Приемке обычно предшествует оценка или тестирование, приемка часто обязательна для перехода к выполнению следующего этапа проекта или процесса. Портфель заказчиков - база данных или структурированный документ, используемые для хранения информации обо всех Заказчиках поставщика услуг. Портфель договоров - база данных или структурированный документ, используемый для управления договорами на оказание услуг или Соглашениями между поставщиками услуг и их заказчиками. Пакет услуг (Service Package) - детализированное описание услуги, доступной для предоставления заказчикам. Запись об изменении (Change Record) - запись, содержащая детальную информацию об изменении. Каждая запись об изменении документирует жизненный цикл одного изменения. Запись об изменении создается для каждого полученного Запроса на изменение, даже если он впоследствии отклонен (отвергнут). Запись об изменении должна содержать информацию о конфигурационных единицах, которые затрагивает данное изменение. Записи об изменениях хранятся в Системе управления конфигурациями. График изменений (Change Schedule) - документ, в котором перечислены все утвержденные изменения и их плановые сроки внедрения. Ожидаемый простой услуги (Projected Service Outage или PSO) - документ, определяющий влияние спланированных изменений, деятельности по обслуживанию и планов испытаний на согласованный уровень услуг. Комитет по изменениям(Change Advisory Board или CAB) - группа людей, консультирующих менеджера по изменениям при выполнении им оценки соответствия, приоритезации и планирования изменений. Этот комитет обычно формируется из представителей всех заинтересованных сторон - поставщика услуг, бизнеса и третьих сторон, таких как прочие поставщики. Комитет по срочным изменениям (Emergency Change Advisory Board или ECAB) группа людей в составе Комитета поизменениям, которые принимают решения по Срочным изменениям с высоким влиянием. Необходимость участия в ECAB может быть выявлена непосредственно при созыве (организации) совещания и определяется исходя из сути Срочного изменения. Управление активами и конфигурациями (Service Asset and Configuration Management или SACM) - процесс, ответственный за Управление конфигурациями и Управление активами. Конфигурационная единица (Configuration Item или CI) - любой компонент, который нуждается в управлении для того, чтобы предоставлять услугу. Информация о каждой КЕ регистрируется в форме Записи о КЕ в Системе управления конфигурациями и поддерживается актуальной в течение всего жизненного цикла процессом Управления конфигурациями. КЕ находятся под контролем Управления изменениями. Типичными примерами КЕ являются услуги, оборудование, программное обеспечение, здания, люди и документы, такие как Процессная документация и Соглашения об уровне услуг (SLA). Интерфейс поставщика услуг (Service Provider Interface или SPI) - интерфейс между поставщиком услуг и пользователем, заказчиком, бизнес-процессом, или поставщиком. Анализ интерфейсов поставщика услуг помогает координировать сквозное управление услугами. Библиотека эталонного ПО (Definitive Media Library (DML) - одно или несколько защищенных хранилищ, в которых находятся определенные и авторизованные версии всех конфигурационных единиц, относящиеся к программному обеспечению. DML также может содержать CI, ассоциированные с ПО, такие как лицензии и документация. DML является логически единым хранилищем, даже если физически места хранения распределены. Все программное обеспечение в DML находится под контролем Управления изменениями и Управления релизами, должно быть зарегистрировано в Системе правления конфигурациями. В релизе может быть использовано только программное обеспечение из DML. Единица релиза (Release Unit) - компоненты услуги, которые обычно компонуются вместе и выпускаются в рамках одного релиза. Единица релиза обычно включает в себя компоненты, необходимые для выполнения какой-либо полезной функции. Например, Единицей релиза может быть настольный компьютер, включающий в себя программное, аппаратное обеспечение, лицензии, документацию и т.п. Другим примером Единицы релиза может служить целое приложение для расчета зарплаты, включая процедуры операционного управления IT и тренинги пользователей. Пилот (Pilot) - ограниченное развертывание услуги, релиза или процесса в среде промышленной эксплуатации. Пилот используется для сокращения рисков и получения обратной связи, а также приемки от пользователей. Базовое состояние (Baseline) - зафиксированное состояние, используемое как ориентир (контрольная точка). Поддержка в начале эксплуатации (Early Life Support или ELP) - поддержка, предоставляемая в отношении новой или измененной услуги в течение некоторого времени непосредственно после того, как услуга была введена в эксплуатацию. Во время поддержки в начале эксплуатации поставщик услуг может пересматривать ключевые показатели производительности, уровни услуги и наблюдаемые пороговые значения, а также задействовать дополнительные ресурсы для Управления инцидентами и Управления проблемами. Обходное решение (Workaround) - уменьшение или устранение влияния инцидента или проблемы, для которых в текущий момент недоступно полное разрешение. Например, перезапуск отказавшей конфигурационной единицы. Обходные решения для проблем документируются в записях об известных ошибках. Обходные пути для инцидентов, которые не привязаны к записям о проблемах, документируются в записях об инцидентах. Подтверждение(Validation) - деятельность, которая гарантирует, что новая или измененная услуга, процесс, план или другой результат отвечает нуждам бизнеса. Подтверждение гарантирует, что требования бизнеса удовлетворены, даже если они могли измениться по отношению к исходному результату проектирования. Подтверждение и тестирование услуг (Service Validation and Testing) - процесс, ответственный за подтверждение и тестирование новой или измененной услуги. Подтверждение и тестирование услуг удостоверяется, что услуга соответствует ее спецификации проектирования и будет отвечать потребностям бизнеса. Оценка (Evaluation) - процесс, ответственный за проведение оценки новой или изменяемой услуги для обеспечения управления рисками и помощи в принятии решения о продолжении проведения изменения. Управление знаниями (Knowledge Management) - процесс, отвечающий за сбор, анализ, сохранение и предоставление знаний и информации в Организации. Первичная цель Управления знаниями - увеличение эффективности путем снижения необходимости в повторном поиске знаний. Данные-Информация-Знания-Мудрость (Data-to-Information-to-Knowledge-toWisdom или DIKW) - способ представления взаимосвязей между данными, информацией, знанием и мудростью. Концепция DIKW показывает, каким образом каждое из перечисленных понятий базируется на остальных. Контроль операционного управления (IT Operations Control) - функция, отвечающая за мониторинг и контроль услуг и IT-инфраструктуры. Операционное управление IT (IT Operations) - деятельности, выполняемые функцией Контроля операционного управления ИТ, в том числе консольное управление, планирование задач, резервное копирование, восстановление, печать и управление выводом. Роль - набор ответственностей, деятельностей и полномочий, присвоенных сотруднику или команде. Роль определяется в процессе. Один сотрудник или команда может иметь (выполнять) много Ролей. Например, Роли Менеджера Конфигураций и Менеджера Изменений могут выполняться одним сотрудником. Управление событиями (Event Management) - процесс,ответственный за управление событиями в течение жизненного цикла. Управление событиями одна из главных деятельностей операционного управления ИТ. Событие (Event) - изменение состояния, которое имеет значение для управления конфигурационной единицей или услугой. Активный мониторинг (Active Monitoring) - мониторинг конфигурационных единиц или услуг, использующий автоматизированные регулярные проверки для отслеживания текущего статуса объекта мониторинга. Пассивный мониторинг (Passive Moitoring) - мониторинг конфигурационной единицы, услуги или процесса, который основывается на предупреждениях или уведомлениях о текущем состоянии. Управление инцидентами (Incident Management) - процесс, отвечающий за управление жизненным циклом всех инцидентов. Основная цель Управления инцидентами - скорейшее восстановление услуги для пользователей. Инцидент (Incident) - незапланированное прерывание услуги или снижение качества услуги. Сбой конфигурационной единицы, который еще не повлиял на услугу, также является инцидентом. Например, сбой одного диска из массива зеркалирования. Срочность (Urgency) - мера того, насколько быстро с момента своего появления инцидент, проблема или изменение приобретет существенное влияние на бизнес. Например, инцидент с высоким уровнем влияния может иметь низкую срочность до тех пор, пока это влияние не затрагивает бизнес в период закрытия финансового года. Влияние и срочность используются для назначения приоритета. Эскалация (Escalation) - деятельность, направленная на получение дополнительных ресурсов, когда это необходимо для достижения Целевых показателей уровня услуги или ожиданий заказчиков. Эскалация может потребоваться в рамках любого процесса Управления услугами, но наиболее часто ассоциируется с Управлением инцидентами, Управлением проблемами и управлением жалобами заказчика. Существует два типа эскалации: функциональная эскалация и Иерархическая эскалация. Управление запросами на обслуживание (Request Fulfillment) - процесс, ответственный за управление жизненным циклом всех запросов на обслуживание. Управление проблемами (Problem Management) - процесс, отвечающий за управление жизненным циклом всех проблем. Ключевыми целями Управления проблемами являются предотвращение инцидентов и минимизация влияния тех инцидентов, которые не могут быть предотвращены. Проблема (Problem) - причина одного или нескольких инцидентов. Диаграмма Ишикавы - методика, помогающая команде определить все возможные причины проблемы. Первоначально была разработана Каору Ишикавой (Kaoru Ishikawa), результатом работы этой методики является диаграмма. База известных ошибок (Known Error Database или KEDB) - база данных, содержащая все записи об известных ошибках. Эта база данных создается в процессе Управления проблемами и используется процессами Управления инцидентами и проблемами. База известных ошибок это часть Системы управления знаний по услугам (SKMS). Управление доступом (Access Management) - процесс, отвечающий за допуск пользователей к использованию услуг, данных или других активов. Управление доступом помогает обеспечить конфиденциальность, целостность и доступность активов за счет того, что только авторизованные пользователи имеют возможность получить доступ или модифицировать активы. Идентификатор (Identity) - уникальное наименование, используемое для идентификации пользователя, человека или роли. Идентификатор используется для предоставления прав пользователю, человеку или роли. Примерами идентификации могут быть имя пользователя Иванов Иван или Роль "Менеджер Изменений". Непрерывное улучшение услуг (Continual Service Improvement или CSI) постоянное улучшение услуг отвечает за управление улучшениями (совершенствованием) в процессах Управления услугами и предоставлении услуг. Производительностьпоставщика услуг постоянно измеряется, и разрабатываются меры по улучшению процессов, услуг и ИТинфраструктуры с целью увеличения эффективности, результативности и эффективности затрат. Зафиксированное состояние (Benchmark) - состояние чего-либо, зафиксированное на определенный момент времени. Зафиксированное состояние может быть создано для конфигурациям, Процесса или любого другого набора данных. Сравнение состояний (Benchmarking) - сравнение зафиксированного состояния с базовым состояние или с лучшей практикой. Термин сравнение состояний также используется в следующем смысле - создание серии зафиксированных состояний в течении определенного отрезка времени и сравнение полученных результатов для оценки прогресса или улучшения. Система сбалансированных показателей (Balanced Scorecard) - инструмент управления, разработанный докторам Робертом Капланом (Гарвадская бизнес-школа, Harvard Business School) и Дэвидом Нортоном. Система сбалансированных показателей позволяет декомпозировать Стратегию до Ключевых показателей производительности (KPI). Соотнесение Производительности с KPI используется для демонстрации успешности исполнения Стратегии. Сбалансированный показатель состоит из 4-х главных блоков (областей, направлений), каждый из которых включает в себя небольшое количество KPI.