Если у вас возникли сложности с курсовой, контрольной, дипломной, рефератом, отчетом по практике, научно-исследовательской и любой другой работой - мы готовы помочь.
Предоплата всего
Подписываем
Концепция управления ИТ-услугами
Непосредственная зависимость большинства бизнес-процессов организации от ИТ меняет сегодня отношение к высоким технологиям, одновременно повышая требования к работе ИТ-подразделений. Актуальность темы управления ИТ-услугами на основе стандартов, примером которых может служить библиотека ITIL, не подлежит сомнению. Наибольшую известность к сегодняшнему дню завоевала модель ITSM HP Reference Model, однако есть и другие подходы к управлению ИТ-услугами. Один из них предлагает методология Microsoft Operations Framework.
Сегодня стандартом де-факто в области управления обслуживанием информационных систем считается библиотека ITIL, разработанная в конце 80-х годов по заказу английского правительства и ставшая сборником лучшего мирового опыта в области управления качеством предоставляемых ИТ-услуг.
Многие компании предложили свои подходы к реализации идей, заложенных в ITIL. Наибольшую известность получила модель Hewlett-Packard — ITSM HP Reference Model. Корпорация Microsoft не осталась в стороне от этого процесса и в 2000 году предложила опирающуюся на ITIL методологию Microsoft Operations Framework (MOF) дополнения и изменения, внесенные в MOF по сравнению с ITIL, позволяют использовать ее в гетерогенных средах.
|
Рис. 1. Инициатива Microsoft Enterprise Services |
MOF, наряду с Microsoft Solutions Framework (MSF) и Microsoft Readiness Framework (MRF), является одной из составляющих инициативы Microsoft Enterprise Services (рис. 1). Каждая из этих методологий позволяет управлять информационной системой на определенной стадии ее развития. MOF фокусируется на эксплуатации информационной системы, MSF — на ее построении и внедрении, а MRF —на стадии подготовки. (Для стадии планирования у корпорации нет четко оформленной методологии; предлагается только ряд средств и служб, систематизирующих процессы, которые протекают в информационной системе на этой стадии.)
MOF состоит из набора статей (white papers), руководств (operations guides), служб, материалов обучающих курсов и включает в себя три основные модели: процессов (MOF Process Model); команды (MOF Team Model); управления рисками (MOF Risk Model). Каждая из моделей фокусируется на внедрении лучшего практического опыта в своей области.
|
Рис. 2. Модель процессов MOF |
Эту модель можно представить как расширение и реорганизацию процессов, описанных в книгах «Предоставление ИТ-услуг» и «Поддержка ИТ-услуг» библиотеки ITIL. В MOF Process Model собраны процессы управления обслуживанием информационных систем, которые представлены в виде функций управления услугами (Service Management Functions, SMF). Модель процессов предполагает, что команда, обслуживающая информационную систему, ответственна за управление всеми изменениями в инфраструктуре. Наиболее эффективный путь контроля над такими изменениями — группировка родственных служб в серию так называемых «выпусков» (групп изменений), каждый из которых может планироваться и управляться отдельно. Модель процессов MOF описывает жизненный цикл каждого выпуска. Процессная модель MOF представлена в виде 20 SMF-функций, распределенных на четыре квадранта (рис. 2, таблица 1).
|
Таблица 1. Распределение SMF-функций |
Большинство SMF-функций основаны на процессах ITIL. Исключение составляют функция «Управление людскими ресурсами» из квадранта «Оптимизация» и все функции из квадранта «Обслуживание». Отсутствие соответствующих процессов в библиотеке ITIL объясняется ее независимостью от конкретной платформы. В результате в MOF именно для процессов, представленных в квадранте «Обслуживание», предусмотрено большинство руководств (operations guide), конкретизирующих их применение для продуктов и технологий Microsoft.
Квадрант «Изменение»
Функции квадранта требуются для идентификации, оценки необходимости и одобрения изменений, вносимых в информационную систему, а также учета составляющих ее компонентов.
Квадрант «Обслуживание»
В этот квадрант входят стандартные процедуры обслуживания информационных систем, направленные на достижение заранее оговоренного уровня услуг. Целью выполнения всех процессов является предсказуемое поведение системы. Для этого обслуживающий персонал должен иметь подробные руководства по поддерживаемым системам. (В частности, именно такие руководства предоставляет MOF в серии Windows 2000 Operations Guide.)
Квадрант «Поддержка»
Квадрант содержит процессы необходимые для разрешения и предупреждения проблемных ситуаций, возникающих во время эксплуатации информационной системы. Процессы несут в себе как реактивную (оперативное решение проблем), так и превентивную (предотвращение проблем) составляющие.
Цель функций квадранта — управление оптимизацией стоимости, доступности, производительности ИТ-услуг, а также сохранение и улучшение их зафиксированного уровня предоставления.
Все функции управления услугами являются результатом анализа накопленного практического опыта и вместе с тем требуют уточнения при внедрении в конкретной рабочей среде.
Модель команды MOF Team Model позволяет упростить процесс создания распределенной команды, управляющей территориально распределенной ИТ-инфраструктурой. MOF Team Model схожа с MSF Team Model; различие состоит в том, что вторая модель сфокусирована на ролях и целях команды разработчиков, а первая — на команде, обслуживающей информационную систему. Еще одним источником знаний модели команды MOF явился опыт по построению организационной структуры, почерпнутый из ITIL. Модель команды MOF описывает:
Для построения успешной и эффективной команды требуется несколько больше, чем просто иметь описание ролей и зон ответственности. Также требуется наличие общих принципов организационной культуры, стремление предоставлять качественные услуги пользователям, понимание целей бизнеса компании, максимальное использование средств автоматизации, умение создать и сохранить прочную ИТ-команду.
Понимание всеми членами команды этих, казалось бы, вполне очевидных принципов очень важно, поэтому донесение их до каждого сотрудника становится одной из основных задач менеджера ИТ-подразделения. Главное, что должен понимать ИТ-персонал — данное подразделение является полноправным участником бизнеса компании, оказывающим влияние на формирование добавленной стоимости.
|
Рис. 3. Модель команды MOF |
В модели команды MOF описаны шесть ролей, сгруппированных по функциональному признаку (рис. 3). Важно отметить, что эти роли фактически являются видами деятельности, объединенными общими целями (таблица 2).
|
Таблица 2. Роли и цели |
Как таковая, модель команды не предназначена для описания трудовых обязанностей и не является организационной диаграммой. Фактические функциональные обязанности и конкретные организационные диаграммы могут сильно отличаться в зависимости от масштаба и требований организации. Множество людей может быть вовлечено в выполнение одной роли, один человек может выполнять несколько ролей. «Общение между ролями» (Communication) находится в центре модели команды MOF, в качестве ключевого компонента, необходимого для успешной организации процесса работы команды. Эффективное и оперативное общение важно для всех ролей, однако оно особенно важно для роли «Поддержка», осуществляющей постоянное взаимодействие с пользователями/потребителями ИТ-услуг.
|
Рис. 4. Связь между процессами и ролями в MOF |
Связь между квадрантами модели процессов и ролями в MOF представлена на рис. 4. Множество ролей может быть связано с функциями одного квадранта, а одна роль может существовать в нескольких квадрантах.
Существует очень много моделей и технологий управления рисками, но все они характеризуются наличием процесса планирования неопределенного будущего. Модель управления рисками в процессе эксплуатации системы MOF Risk Model — не исключение. Она адаптирована для случаев возникновения проблем, с которыми обслуживающий ИТ-персонал сталкивается каждый день. В Microsoft позаботились о MOF Risk Model с тем, чтобы гарантировать, что практика превентивного управления рисками встроена в каждую роль и SMF-функцию, а персонал, занимающийся эксплуатацией информационных систем, применяет методы управления рисками к проблемам, с которыми сталкивается ежедневно.
Как и в случае с моделью команды MOF, модель управления рисками MOF создана на основе аналогичной модели MSF. Их различие — только в фокусе: MSF Risk Model ориентируется на риски, относящиеся к разработке, а MOF Risk Model — на риски, специфичные для обслуживания информационной системы.
|
Рис. 5. Модель управления рисками MOF |
Рис. 5 иллюстрирует пять этапов модели управлением рисками. Важно понимать, что каждый риск проходит все пять этапов и часто — не один раз. Каждый риск имеет свою временную шкалу, так что в любой момент времени несколько рисков могут находиться на каждом этапе.
Методология MOF создавалась не на пустом месте и стала развитием принципов ITIL, внеся свой вклад в формирование стандартов организации обслуживания информационных систем. Внедрение MOF поможет организации наладить эффективное функционирование информационной системы, решающей поставленные бизнесом задачи. Начать корректировку деятельности ИТ-подразделения компании можно с внедрения любого описанного в MOF процесса. Однако наиболее логичным представляется путь, когда стартовой точкой является внедрение ServiceDesk. Это связано с ключевой ролью, которую играет этот процесс — единая и единственная служба, посредством которой потребители ИТ-услуг взаимодействуют с ИТ-департаментом. Кроме того, на ServiceDesk завязаны практически все остальные функции MOF.
MOF обладает рядом существенных особенностей по сравнению с ITIL. Прежде всего, методология представляет расширенную модель процессов и концепцию функций управления услугами (Service Management Functions, SMF). Добавлены ключевые процессы, не включенные в ITIL. Модель процессов дополнена моделями команды и управления рисками. В противовес документам чисто описательного характера, свойственным ITIL, предоставлены прикладные материалы, такие, как документы серий Windows 2000 Operations Guide, Exchange 2000 Operations Guide и т.д.
В современную редакцию библиотеки ITIL входят восемь книг: Software Asset Management, Service Support, Service Delivery, Planning to Implement Service Management, ICT Infrastructure Management, Application Management, Security Management, Business Perspective.
Внедрение и использование передовых информационных технологий требует понимания ИТ-инфраструктуры, взаимосвязи ее компонентов, строгого распределения обязанностей, зон ответственности, наличия информации о состоянии системы в целом и ее компонентов, о задачах, выполняемых пользователями, о тех функциях, которые для них наиболее важны. Как связать столько разнородных процессов в единую модель? Как сформулировать функции системы и сотрудников? Как получить информацию о текущем состоянии системы? Какие критерии использовать при выборе направления развития системы? Как найти грань между потребностями пользователей и возможностями системы и ИТ-департамента? Все эти вопросы должны решаться в рамках единого подхода, единого языка описания архитектуры информационной системы, функций и обязанностей, документации и интерфейсов. Требуется подход, одинаково понятный руководителям и сотрудникам ИТ-отделов, пользователям, поставщикам средств управления. Иными словами, требуется общая, доступная и принятая всеми методологическая основа управления ИТ.
Предметом рассмотрения ITIL является предоставление и поддержка ИТ-услуг, соответствующих бизнес-потребностям предприятия. Сервисная ориентация определяет подход к взаимодействию ИТ-отдела и бизнес-подразделений и предполагает предоставление бизнес-подразделениям услуг в сфере ИТ - в противоположность «технологическому» подходу, при котором ИТ-отдел предоставляет системы, программы, модули и т.п. Услуги при этом описываются и характеризуются в терминах и с точки зрения бизнес-процессов, так же определяется уровень, на котором предоставляются услуги. Создается основа для эффективного взаимодействия, при котором, с одной стороны ИТ-инфраструктура соответствует требованиям и ожиданиям бизнеса, а с другой - определяются критерии оценки качества работы ИТ.
Процессный подход описывает управление ИТ-инфраструктурой как комплекс процессов, затрагивающих различные структурные подразделения и направленных на достижение определенных целей. Для каждого процесса определяются роли, процедуры, входящая и исходящая информация. Деятельность по процессу предполагает эффективное ролевое взаимодействие, направленное на достижение поставленной цели независимо от места участников процесса в организационной структуре ИТ-департамента.
В процессной модели ITIL выделяются следующие процессы управления ИТ:
В части взаимодействия бизнес-подразделений и ИТ-департамента в процессной модели ITIL можно выделить три уровня: операционный (взаимодействие с пользователями), тактический (взаимодействие с заказчиками) и стратегический (согласование целей бизнеса и ИТ).
Процессы операционного уровня
Цель процесса Управления инцидентами (Incident Management) - обеспечение непрерывности предоставления услуг. Основная задача - скорейшее восстановление услуг на согласованном уровне в случае сбоя (или угрозы сбоя). Акцент при этом делается не на надежность, универсальность или системность решения, а на скорость восстановления; отражением этого служит введение понятия «обходное решение».
Выделение в отдельный процесс «борьбы с последствиями» позволяет обеспечить непрерывное предоставление услуг и создать тем самым временную и ресурсную базу для расследования и устранения причин сбоев в рамках процесса Управления проблемами (Problem Management). Его цель - минимизация перебоев в предоставлении услуг, для чего решаются задачи идентификации, расследования и устранения причин возникновения сбоев. Данный процесс анализирует инфраструктуру и формирует предложения по ее изменению с целью повышения стабильности.
Предложения, формализованные в Запросах на изменения (Request For Change), служат входящей информацией для процесса Управления изменениями (Change Management), цель которого - обеспечить управляемое эффективное изменение ИТ-инфраструктуры. В рамках процесса определены процедуры оценки, планирования, реализации и контроля изменений, ответственность, роли и стандартная документация.
Основу для анализа инфраструктуры и проведения изменений дает ее логическая модель, формируемая и поддерживаемая в рамках процесса Управления конфигурацией (Configuration Management). В ITIL используется понятие конфигурационной единицы (Configuration Item), т.е. значимого для предоставления услуг элемента инфраструктуры. Управление конфигурацией описывает характеристики и связи всех конфигурационных единиц. К их числу отнесены не только программные и аппаратные средства, но и документация, процедуры, элементы организационной структуры. Такой комплексный подход к описанию инфраструктуры позволяет эффективнее проводить ее анализ и изменение, а также делает ее прозрачнее с точки зрения предоставления услуг, ведь для каждой описанной ИТ-услуги определены связанные конфигурационные единицы.
В связи с особой значимостью программ в предоставлении подавляющего большинства услуг особенности управления конфигурацией и изменениями в программном обеспечении описаны как особый процесс - Управление релизами (Release Management).
Для обеспечения эффективной поддержки пользователей и взаимосвязи процессов операционного уровня используется служба поддержки. ITIL определяет цели и задачи службы, описывает процедуры ее работы и содержит рекомендации по эффективной организации Service Desk.
Процессы тактического уровня
Основой взаимодействия ИТ-департамента и бизнес-подразделений служат Соглашения об уровне обслуживания (Service Level Agreement), описывающие параметры предоставления ИТ-услуг. Взаимодействие с заказчиками, выработка и поддержание соглашений, контроль и коррекция уровня обслуживания - вот задачи, решаемые процессом Управления уровнем обслуживания (Service Level Management). Процесс также обеспечивает связь между характеристиками услуг с точки зрения заказчиков и параметрами их предоставления с точки зрения ИТ. Согласование уровня обслуживания подразумевает определение услуг, наиболее критичных для бизнеса, гарантированная готовность которых определяет успешность бизнеса в целом; соответственно выделяются и наиболее критичные системы инфраструктуры.
На решение вопросов готовности услуг в условиях нормальной работы направлен процессу Управления готовностью (Availability Management), а в форс-мажорных обстоятельствах - процесс Управления непрерывностью (Continuity Management).
Оптимальное использование ресурсов инфраструктуры в соответствии с требованиями бизнеса к уровню обслуживания и тенденциями развития инфраструктуры - цель процесса Управления мощностями (Capacity Management). Четкое определение параметров предоставления услуг и их связи с элементами инфраструктуры, формализованные требования к готовности и непрерывности, прогнозирование развития в рамках управления мощностями - все это создает основу для корректного определения стоимости предоставления каждой услуги.
Обеспечивается финансовая прозрачность ИТ-департамента, затраты напрямую связываются с бизнес-требованиями - за это отвечает процесс Управления финансами (Financial Management for IT Services).
ITIL - один из немногих примеров, когда профессиональные консалтинговые компании поделились своими знаниями. Между тем, библиотека в первую очередь указывает, на что следует обратить внимание в организации ИТ, что в ней должно быть улучшено, но не дает прямых указаний, как это можно сделать. Однако ответ на вопрос «как» зачастую достаточно труден (во многом из-за специфики конкретного предприятия); определить общие принципы в применении ITIL непросто. Показательно, что опытные консультанты в области ITSM стараются не следовать слепо каким-либо схемам внедрения и не давать рекомендаций, пока не выявлены первоочередные проблемы заказчика. Кстати, один из советов ITIL - двигаться путем «быстрых побед», т.е. решая наиболее острые задачи; именно это должно ставиться во главу угла, а не внедрение ITSM как таковое. Так достигается наибольшая эффективность проекта.
В то же время, несколько крупных ИТ-компаний с учетом собственного опыта постарались сформулировать определенные принципы в применении ITIL. Заказчики получают возможность понять некоторую генеральную линию в применении ITIL, предлагаемую компаниями, и выбрать вариант ответа на вопрос о том, «как» ITIL можно было бы применить у них. Многие из этих подходов не противоречат друг другу; их элементы могут быть комбинированы. Фактически Управление ИТ-услугами стало объединением различных подходов, возникших на основе библиотеки ITIL.
Подобные подходы существуют у ряда ведущих игроков ИТ-рынка (в частности, у HP, IBM и Microsoft). Некоторые из них не раскрывают детали, по праву считая их инструментом собственного консалтинга. Кроме того, не все из них активно продвигают на российском рынке свои идеи и услуги в этой области. Первой в России в конце 90-х годов начала предлагать проекты на основе ITSM компания HP.
ITSM Reference Model
Методика HP - ITSM Reference Model - заслуживает серьезного внимания, особенно для тех, кто хотел бы произвести радикальные преобразования. В HP группируют обозначенные в ITIL процессы в пять блоков: Согласование задач бизнеса и ИТ (Business IT Alignment); Разработка и управление услугами (Service Design&Management); Разработка и распространение услуг (Service Design&Deployment); Операционные задачи ИТ (Operations Bridge); Гарантии предоставления услуг (Service Delivery Assurance). При этом первые четыре блока принято рассматривать как следующие друг за другом в рамках жизненного цикла работы ИТ-департамента, а в центр помещать пятый блок, отвечающий за предоставление услуг. Но несмотря на это ITSM Reference Model допускает произвольную последовательность внедрения в зависимости от особенностей предприятия.
MOF
Пожалуй, из всех предложенных ITSM-подходов наибольшей доступностью для изучения обладает Microsoft Operations Framework (MOF). В его основе лежат три модели: Модель процессов (Process Model), Модель организационных команд (Team Model) и Модель рисков (Risk Model). Модель процессов состоит из четырех квадрантов, включающих в себя Функции управления услугами (Service Management Function, SMF). Многие из этих функций повторяют процессы ITIL, но есть и ряд дополнительных, которые предложены Microsoft, исходя из собственного опыта эксплуатации ИТ-инфраструктуры и опыта партнеров.
Данная модель дает взгляд на работу ИТ-инфраструктуры с точки зрения жизненного цикла ИТ-услуг от момента их создания и до момента оптимизации или замены новыми услугами. В частности, в модели нашел отражение опыт Microsoft по выводу на рынок новых приложений через организацию многоуровневых тестовых испытаний, что дает предприятиям опыт подготовки и сдачи в эксплуатационную среду новых аппаратно-программных решений. Идеи, изложенные в рамках MOF, не зависят от конкретных аппаратно-программных платформ. В то же время, MOF активно используется Microsoft как при разработке программных средств управлениях ИТ, так и при разработке эксплуатационной документации на все выпускаемые в настоящее время программные продукты.
ITPM
Предложенная в конце 70-х годов для решения задач управления компьютерными системами архитектура ISMA (Information Systems Management Architecture) мало чем напоминала современную библиотеку ITIL. По сути ITPM (IT Process Model), возникшая из ISMA, отличается от ITIL не только по способу деления процессов, но и по ряду терминологических моментов. В реальности, IT Process Model - не модель в ее практическом понимании, а среда разработки прикладной модели. Тем не менее, преобразованная на основе анализа опыта выполнения ИТ-проектов, ITPM органично сочетается с ITIL.
ITPM включает семь групп процессов по числу факторов, влияющих на успех любого ИТ-проекта: улучшение взаимодействия с клиентами; обеспечение управленческих систем корпоративной информацией; управление ИТ с точки зрения потребностей бизнеса; реализация и развертывание решений; обеспечение услугами; поддержка ИТ-услуг и решений; управление ИТ-ресурсами и инфраструктурой.
Процессный подход
Каждая организация нацелена на выполнение своих корпоративных целей и миссии, решение стратегических задач и реализацию выбранной политики. Это достигается через выполнение определенной деятельности. Необходимо структурировать работы, которые направлены на достижение поставленной цели, то есть организовать их таким образом, чтобы было видно, как каждая группа работ способствует решению стратегических задач и как эти группы связаны между собой. Такие группы организованной между собой деятельности называются процессами. В случае, если процессная структура организации четко определена, то она дает ответы на вопросы:
1. Что должно быть сделано.
2. Какой ожидается результат.
3.Каким образом можно определить (измерить), что в результате работы процесса достигается ожидаемый результат.
4. Как результаты выполнения одного процесса влияют на результаты других процессов.
Вопросы, представленные на рис. 1а постоянно возникают при использовании процессного подхода,
типичного для современного ИТ предприятия. Средства для нахождения ответов на них приведены в
правой части рисунка.
Рис.1а Модель совершенствования процессов
При организации работ в виде процессов не учитываются не существующее распределение работ, ни деление Фирмы на отделы. Это сознательный выбор. Делая выбор в пользу процессной структуры, можно доказать, что некоторые виды работ на Фирме не координируются, дублируют друг друга, игнорируются или вообще не нужны. Вместо этого мы сосредотачиваемся на цели процесса и его взаимоотношениях с другими процессами.
Процесс — это последовательность работ, нацеленная на преобразование входных данных Service Desk (main process) 21.09.2007 (версия 1.1) (информации, документации и т. д.) в выходные. Для получения информации о том, каким будет результат выполнения процесса, нужно проверить вход и выход каждого процесса на соответствие характеристикам качества и стандартам. В результате этого получаются цепочки процессов, по которым можно отследить, что происходит в организации и какой
результат получается, а также определить контрольные точки в этих цепочках, в которых выполняется мониторинг качества продуктов и услуг, предоставляемых организацией. Стандарты для выходных данных каждого процесса должны быть определены таким образом, чтобы вся цепочка процессов обеспечивала достижение корпоративных стратегических целей. Если результат процесса отвечает заданному стандарту, такой процесс будет считаться эффективным (effective). Если работы в рамках данного процесса к тому же выполняются с наименьшими усилиями и затратами, этот процесс будет рациональным (efficient)1. Цель Управления Процессами — планировать и контролировать процессы таким образом, чтобы они были одновременно эффективными и рациональными. Для оптимизации качества процессов каждый из них можно рассматривать отдельно. Владелец процесса несет ответственность за результаты работы процесса. Менеджер процесса отвечает за его структуру и выполнение и подотчетен владельцу процесса. Координаторы процесса отвечают за выполнение заданных видов работ и отчитываются о их результатах выполнения менеджеру процесса. Логическая структуризация работ внутри процесса позволяет установить четкие точки перехода, в которых есть возможность выполнять мониторинг качества процесса. Руководство организации может осуществлять контроль, основываясь на информации о качестве каждого из процессов. В большинстве случаев соответствующие показатели эффективности и стандарты уже будут предопределены Соглашениями. Поэтому каждодневный контроль процесса передается Руководителю (менеджеру) Процесса.
Владелец процесса будет оценивать работу по показателям производительности и их соответствию согласованному стандарту. Без четких показателей владельцу процесса будет трудно определить степень контролируемости процесса и реализации запланированных улучшений.
Управление ИТ-сервисами (ITSM)
Для многих ИТ-организаций синонимом эффективности становится сегодня модель
функционирования, основанная на основе библиотеки ITIL, которая систематизирует
лучшие практики работы ИТ-департаментов, помогая сформулировать цели ИТ
подразделений, задать параметры измерения прогресса в достижении этих целей, оценить
результаты и определить возможные действия в случае, когда они оказываются
1 Суть терминов «effective» и «efficient» можно также проиллюстрировать выражениями «делать правильные вещи» и «делать
вещи правильно».
Service Desk (main process) 21.09.2007 (версия 1.1) 6
несоответствующими поставленным целям. Процессы и сервисы, краеугольные камни
модели ITIL. Согласно построенной на базе ITIL методологии управления ИТ-сервисами (ITSM), ИТ департамент превращается в сервисное подразделение, предоставляющее свои услуги бизнесу. Цель процессов ИТ Сервис-менеджмента — содействовать повышению качества ИТ услуг. Управление Качеством и контроль процессов являются частью организации и ее политики. Предоставление нужных сервисов надлежащего качества в ITIL/ITSM базируется на процессной организации работы Службы. Центральными для модели ITIL/ITSM являются две группы процессов (см. рис. 1), обеспечивающие поддержку услуг и их предоставление. Процессы группы поддержки сервисов называют также
оперативными, поскольку они включают в себя повседневные функции информационного департамента, обеспечивающие реализацию ИТ-сервисов. Процессы второй группы относят к тактическим процессам, гарантирующим предоставление услуг с заданным качеством.
Для решения основной задачи данного документа, нас будет интересовать вопросы,
относящиеся к Поддержке сервисов.
Задачи Service Desk
Service Desk должен быть - единой точкой контакта между клиентами (пользователями) и ИТ специалистами, от приема обращений, до оказания квалифицированной технической поддержки. Ключевые задачи Службы указаны в таблице 1. Техническая поддержка, как процесс, может иметь несколько уровней, но обычно их три.
Первый уровень — это сама центральная служба технической поддержки, она же Service
Desk. Сюда со своими проблемами обращаются все пользователи, и попытки обратиться
напрямую к инженерам пресекаются. Это нужно, чтобы не отвлекать
высококвалифицированных специалистов на решение простых задач.
Второй уровень поддержки — так называемые технические специалисты, которые владеют
глубокими знаниями по определенным технологическим направлениям, например, по SQL-
серверу или очень хорошо разбираются в работе веб-серверов.
Третьим уровнем может быть, группа разработчиков, которая не просто поддерживает
продукт, но и дорабатывает его в соответствии с меняющимися запросами бизнеса. К этому
же уровню можно отнести и специалистов внешних компаний — поставщиков технологий и
услуг.
Переход Инцидента на очередной уровень технической поддержки (Эскалация) означает
увеличение времени и стоимости его разрешения. Разумеется, следует стремиться к тому,
чтобы больше Инцидентов решать уже на первом уровне, где специалисты хотя и
квалифицированные, но значительно более дешевые, чем, на третьем уровне. Схема
маршрутизации Инцидента, показана на рисунке 4, стоит отметить, что на рисунке показана
Функциональная эскалация (горизонтальная). Подробнее об Эскалации, смотрите раздел
«Основная Терминология».
Service Desk (main process) 21.09.2007 (версия 1.1) 10
Рис.4 Уровни поддержки Service Desk
Основная Терминология
Для понимания процессов работы Службы, определимся с основными терминами и их
трактовкой, которая в разных источниках отличается. В ITIL все обращения (Запросы) могут
регистрироваться и отслеживаться, как Инциденты. Однако более правильным будет
следующая градация, когда под Проблемой подразумевается событие, которое может
привести к остановке нормальной работы Сервиса либо значительно ухудшить качество
работы этого сервиса. Под Инцидентом, подразумевается более критические события, в
работе вышеупомянутого Сервиса (выходящее за рамки допустимых величин), когда для
восстановления его работы (либо качества) требует значительное время.
Запрос на обработку Инцидентов – запрос от пользователя в Service Desk, к таким
запросам можно отнести все запросы, как о Проблемах, так и об Инцидентах.
Service Desk (main process) 21.09.2007 (версия 1.1) 11
Запрос на Обслуживание (Service Request) – это запрос от пользователя на предоставление
информации, консультации или документации, не являющийся Запросом о Проблеме.
Примеры Запросов на обслуживание:
• запрос о функционировании или предоставлении информации о работе ПС;
• запрос о возможности работы ПС на новом «железе».
Для того чтобы можно было отличить Инциденты от «Инцидентов-Запросов на
Обслуживание», рекомендуется присваивать Запросам на Обслуживание специальную
категорию. Важно также отметить, что Запрос на Обслуживание это не то же самое, что
Запрос на Изменение.
Запрос на Изменение (RFC) — это устное обращение или экранная (бумажная форма),
используемая для записи детальной информации о предлагаемом запросе на изменение
каких-либо характеристик ПС либо в ИТ инфраструктуре. Запрос RFC считается
завершенным после проведения изменения в инфраструктуре, например, замены
зарегистрированных компонентов, инсталляции ПК и т. д. Это не Инциденты, а изменения.
При одновременной обработке нескольких Инцидентов необходимо расставлять
приоритеты. Обоснованием для назначения приоритета служит уровень важности ошибки
для бизнеса и для клиента. На основе диалога с пользователем и в соответствии с
положениями SLA, Служба назначает приоритеты, определяющие порядок обработки
Инцидентов. При эскалации инцидентов на вторую, третью или более линии поддержки, тот
же приоритет должен быть соблюден, но иногда он может быть скорректирован по
согласованию со Службой.
Каждый пользователь будет считать, что его Инцидент имеет наивысший приоритет, но
мнения пользователей часто бывают субъективными. Для объективной оценки приоритета в
диалоге с пользователем употребляются следующие критерии:
1. степень воздействия инцидента: степень отклонения от нормального уровня предоставления
услуги, выражающаяся в количестве пользователей или бизнес процессов, подвергшихся
воздействию Инцидента;
2. срочность инцидента: приемлемая задержка разрешения Инцидента для клиента или бизнес -
процесса.
Приоритет определяется на основе срочности и степени воздействия. Для каждого
приоритета определяется количество специалистов и объем ресурсов, которые могут быть
направлены на разрешение Инцидента. Порядок обработки инцидентов одинакового
приоритета может быть определен в соответствии с усилиями, необходимыми для
Service Desk (main process) 21.09.2007 (версия 1.1) 12
разрешения инцидента. Например, легко разрешаемый инцидент может быть обработан
перед инцидентом, требующим больших усилий. Степень воздействия и срочность также
могут сами меняться во времени, например, при росте количества пользователей,
подвергшихся воздействию инцидента или в критические моменты времени.
Если инцидент не может быть разрешен первой линией поддержки за согласованное время,
необходимо привлечение дополнительных знаний или полномочий. Это называется
Эскалацией, которая происходит в соответствии с рассмотренными выше приоритетами и,
соответственно, временем разрешения инцидента. Различают функциональную и
иерархическую эскалацию:
Функциональная эскалация (горизонтальная) - это передача Инцидента на
вторую линию поддержки при невозможности устранения инцидента на первой
(привлечение большего количества специалистов). При функциональной эскалации растет
и качество вовлекаемых ресурсов.
Иерархическая эскалация (вертикальная) — означает переход на более высокий
уровень, в рамках организации, так как для разрешения инцидента недостаточно
организационных полномочий (уровня власти) или ресурсов. Она становится необходимой
при невозможности устранения инцидента либо за выделенное время, либо с необходимым
качеством. В отличие от функциональной эскалации, иерархическая эскалация привлекает внимание руководства.__
Основные процессы службы Service Desk
Согласно методологии ITISM основными процессами для Service Desk(a) являются:
Процесс Управления инцидентами (Incident Management) и Процесс Управления
проблемами (Problem Management).
Основная цель процесса Управления Инцидентами — скорейшее восстановление
нормального функционирования сервиса в соответствии с Соглашением об уровне услуг и
минимизация воздействия отказа на жизнедеятельность бизнеса.
Основная цель процесса Управления проблемами — сделать так, чтобы Инцидентов стало
меньше, что достигается за счет выявления и устранения их причин.
Управление Инцидентами
Этот процесс носит реактивный характер (фиксация и разрешения Инцидентов). Его часто
связывают со службой Help Desk. Он направлен на быстрое восстановление обслуживания
путем устранения неполадок, возникающих в инфраструктуре либо в работе ПС. Задача
процесса Управления Инцидентами - свести к минимуму случаи прерывания обслуживания
Service Desk (main process) 21.09.2007 (версия 1.1) 13
или прерывания в работе сервиса. Он играет роль повседневного интерфейса общения
между клиентами и Фирмой, что делает его необходимым для успешного управления
удовлетворенностью клиентов. Процесс можно охарактеризовать как сочетание обработки
обращений и эффективной поддержки первого, второго и третьего уровней. Разграничение
между Инцидентами и Проблемами иногда может запутывать, но его главное отличие
заключается в установлении различия между быстрым восстановлением услуги и
установлением причины инцидента и ее устранением. Все Инциденты регистрируются,
причем качество регистрационной информации определяет эффективность ряда других
процессов. Типовой перечень задач, относящийся к Управлению Инцидентами, и методы
контроля качества его работы указаны в Таблице №3.
Таблица 3 Деятельность по Управлению Инцидентами
Реализация Контроль качества
Прием обращений
Регистрация инцидента
Эскалация инцидента
Классификация инцидентов
Отслеживание истории инцидентов
Разработка структуры Службы Помощи
Создание системы контроля и различной
регламентирующей документации Службы Помощи
Определение приоритетов
Изоляция неполадок
Удаление неполадок
Составление административных отчетов
Уведомление клиентов
Закрытие дела Непрерывное совершенствование процесса
Управление Проблемами
Этот процесс носит превентивный или проактивный характер (позволяющий анализировать ситуацию и предотвращать проблемы еще до их возникновения). Он направлен на снижение числа неполадок производственной среды и реализуется путем изучения источников их возникновения (на основе информации о прошлых Инцидентах). Он также включает анализ тенденций и контроль известных ошибок с расчетом на устранение их источников в долговременной перспективе, а также информирует другие процессы о потенциальных проблемах в инфраструктуре и работе сервисов. Когда причины
установлены (определены источники ошибки), принимается бизнес-решение о том, необходимо ли делать улучшения в инфраструктуре, в программном обеспечении для предотвращения возникновения новых инцидентов. Такие улучшения производятся путем подачи Запросов на Изменение (RFC).
Service Desk (main process) 21.09.2007 (версия 1.1) 14
Процесс Управления Инцидентами начинает действовать с появлением Инцидента и
прекращает свою работу после исправления ситуации. Это означает, что корневая причина
возникновения инцидента не всегда бывает установлена и инцидент может повториться
снова.
Для выяснения корневых причин возникновения как существующих, так и потенциальных
ошибок в предоставлении услуг, в рамках Процесса Управления Проблемами производится
изучение инфраструктуры и имеющихся регистрационных данных, включая базу данных
инцидентов. Такие исследования необходимы из-за сложного и распределенного характера
инфраструктуры, когда связи между инцидентами не всегда бывают очевидными.
Роли и ответственность сотрудников Service Desk
Для распределения обязанностей (ролей) сотрудников службы поддержки, необходимо
учитывать размер организации и основные соглашения уровня обслуживания (SLA), между
Service Desk и бизнесом. Важно помнить, что речь идет об описании ролей, а не позиций.
Service Desk (main process) 21.09.2007 (версия 1.1) 15
Для решения задач Службы необходимо выделить следующие роли:
• Менеджер службы поддержки.
• Аналитик службы поддержки.
Менеджер
У менеджера Service Desk, большинство задач связанны с координацией работы всей
Службы и его непрерывного развития. Основные задачи для него указаны далее:
• Управление ежедневными действиями и аналитиками Службы, оценка работы.
• Мониторинг эффективности работы и составление рекомендаций по ее
совершенствованию.
• Создание и поддержание планов подготовки сотрудников.
• Выработка управляющей отчетности.
• Поддержание процессов, используемых в пределах Службы и развитие новых.
• Создание культуры обслуживания в пределах Службы.
Аналитик (инженер, диспетчер)
Роль аналитика Service Desk ответственна за выполнение ежедневных задач и процессов
Службы. Эта роль, прежде всего, связана с выполнением процесса Управления
Инцидентами. В первые моменты цикла жизни Инцидента, аналитики Service Desk
ответственны за корректную регистрацию и классификацию Инцидента, оказание
начальной поддержки. На стадии начальной поддержки, они ответственны за разрешение
максимального количества Инцидентов, насколько это возможно в пределах определенных
временных рамок. Эти действия напрямую связанны с удовлетворением клиента и
определяют дальнейшую судьбу Инцидента в цепи поддержки.
Аналитики Службы ответственны за назначение Инцидентов, которые не были решены
сразу. Однако их ответственность на этом не заканчивается, они продолжают сохранять
ответственность за Инцидент, чтобы гарантировать, что они продолжают обрабатываться в
соответствии с целями обслуживания, он также информирует клиента о прогрессе работ в
течение всей жизни Инцидента. Как только Инцидент разрешен, аналитик должен
убедиться, что клиент удовлетворен решением, и только потом закрыть инцидент.
Эта роль также включает начальную обработку всех типов Запросов, поступающих в Service
Desk и обслуживания таких внутренних элементов инфраструктуры Service Desk(a),
Отчетность Service Desk
Отчетность Службы, может быть использована для формализации отношений между
клиентами и Фирмой, ожидаемый уровень поддержки (время реакции на запросы и
исполнение запросов) может быть сопоставлен и приведен в соответствие финансированию
и численности Службы. При помощи отчетности можно будет выявить закономерности в
потоке поступающих запросов и выделить «узкие места» в ПС. Для оценки
производительности процесса необходимо четко определить контрольные параметры и
измеряемые оценки, часто называемые показателями эффективности. Отчет по этим
показателям производится регулярно, например раз в неделю, чтобы получить картину
изменений, по которой можно было бы определить тенденции. Примерами таких
параметров являются:
• общее количество инцидентов;
• среднее время разрешения инцидентов;
• среднее время разрешения инцидентов по приоритетам;
• среднее число инцидентов, разрешенных в рамках соглашений (SLA);
• процент инцидентов, разрешенных первой линией поддержки (без эскалации);
• средняя стоимость поддержки на инцидент;
• число решенных инцидентов на одно рабочее место или на одного сотрудника Service Desk;
• инциденты, решенные без посещения пользователя (удаленно);
• число (или процент) инцидентов с первоначально некорректной классификацией;
Service Desk (main process) 21.09.2007 (версия 1.1) 17
• число (или процент) инцидентов, неправильно распределенных в группы поддержки.
Одним из количественных показателей деятельности Service Desk является объем
разрешений инцидентов при первом обращении. Если, например, этот показатель в
отношении технической поддержки продуктов компании N в этом месяце составил 60%, это
значит, что 60% заявок было выполнено специалистами первого уровня и только 40% ушло
на второй._
3.3.2. Поддержка услуг
В книге ITIL по поддержке услуг описывается, как заказчик может получить доступ к соответствую щим услугам для поддержки своего бизнеса. Эта книга охватывает следующие области:
? Служба Service Desk;
? Управление Инцидентами;
? Управление Проблемами;
? Управление Конфигурациями;
? Управление Изменениями;
? Управление Релизами.
Служба Service Desk
Служба Service Desk является точкой контакта пользователя с ИТ-организацией. Ранее в книгах ITIL она называлась службой Help Desk. Основными задачами службы Help Desk были регистра ция, решение и отслеживание инцидентов. Служба Service Desk имеет более широкие функции (на пример, получение Запросов на Изменения) и может выполнять действия, относящиеся к несколь ким процессам.
Управление Инцидентами
Разграничение между инцидентами и проблемами вероятно является одним из самых известных, но не самых популярных вкладов библиотеки ITIL в развитие ИТ Сервис-менеджмента. Хотя это раз граничение иногда может запутывать, но его главное достоинство заключается в установлении разли чия между быстрым восстановлением услуги и установлением причины инцидента и ее устранением. Процесс Управления Инцидентами предназначен для устранения инцидента и быстрого возобнов ления предоставления услуг. Инциденты регистрируются, причем качество регистрационной ин формации определяет эффективность ряда других процессов.
Управление Проблемами Если есть подозрение на проблему в ИТ-инфраструктуре, то целью Процесса Управления Пробле мами является установление корневой причины. Подозрение на существование проблемы может возникнуть из-за наличия инцидентов, но безусловно целью является предотвращение сбоев везде. где это возможно.
Когда причины установлены (определены известные ошибки), принимается бизнес-решение о том, необходимо ли делать улучшения в инфраструктуре для предотвращения возникновения новых ин цидентов. Такие улучшения производятся путем подачи Запросов на Изменение . Необходимо обратить внимание на то, что определение Управления Проблемами, дающееся в ITIL, зна чительно отличается от определения, которое раньше было принято, например, в ИТ-индустрии США.
Управление Конфигурациями Задачами Управления Конфигурациями являются контроль изменяющейся ИТ-инфраструктуры (стандартизация и мониторинг статуса), идентификация Конфигурационных Единиц (инвентариза ция, верификация и регистрация), сбор и Управление Документацией по ИТ-инфраструктуре, а также предоставление информации об ИТ-инфраструктуре для всех других процессов.
Управление Изменениями Управление Изменениями направлено на контроль проведения изменений в ИТ-инфраструктуре. Це лью процесса является определение необходимых изменений и способов их проведения с минималь ным негативным воздействием на ИТ-услуги, при одновременном обеспечении контроля (отслежива нии) изменений посредством консультаций и координации действий со всей организацией. Измене ния производятся по Запросу от Заказчика, из Процесса Управления Проблемами или из некоторых других процессов. Управление Изменениями тесно связано с деятельностью по мониторингу статуса элементов из Процесса Управления Конфигурациями. Внесение изменений производится согласно разработанной схеме, включающей определение, планирование, создание и испытание, принятие окон чательного решения о проведении, внедрение и оценку.
Управление Релизами Релизом называется набор Конфигурационных Единиц , которые совместно тестируются и вводятся в активную рабочую среду. Главной задачей Управления Релизами является обеспечение успешного развертывания релизов, включая интеграцию, проведение тестирования и хранение.
Управление Релизами обеспечивает гарантию того, что в использовании находятся только тестиро ванные и корректные версии авторизованного программного и аппаратного обеспечения. Управле ние Релизами тесно связано с деятельностью по Управлению Конфигурациями и Управлению Изме нениями. Реальное внесение изменений часто осуществляется через действия в рамках Процесса Управления Релизами.
3.3.3. Другие рассматриваемые процессы Существуют два процесса, которые хотя и не являются модулями ITIL в сериях Предоставление ус луг и Поддержка услуг, но связаны ссылками с другими модулями или с ключевыми пунктами дру гих процессов. Управление Отношениями с Заказчиком ИТ1 является процессом, привлекающим все больше внимания, но пока не вошедшим в какой-либо модуль ITIL. Управление Информацион ной Безопасностью было описано в публикации ITIL 1999 г., но формально не является частью се рии Предоставление услуг. Вопросам безопасности в этой книге посвящена отдельная глава.
Управление Взаимоотношениями с Заказчиком ИТ
Передовой опыт многих организаций показывает, что рекомендуется использовать стройный целена правленный подход к организации взаимоотношений с заказчиками, структурированный на нескольких уровнях. Деятельность по Управлению Взаимоотношениями с Заказчиком ИТ включается в несколько процессов (см. также раздел 2.2.5). Служба Service Desk является первой точкой контакта для пользова телей. Однако, заказавший услугу клиент первоначально вступает во взаимодействие с Процессом Уп равления Взаимоотношениями с Заказчиком ИТ. Он помогает выстроить мост между ИТ-организаци ей, традиционно использующей технические подходы к работе, и заказчиками, работающими над реше нием бизнес-задач своего предприятия. Управление Взаимоотношениями с Заказчиком ИТ не является частью серии книг по Предоставлению услуг и не рассматривается в этой ознакомительной книге.
Управление Информационной Безопасностью
Целью Процесса Управления Информационной Безопасностью является защита ИТ-инфраструкту ры от несанкционированного использования (например, от несанкционированного доступа к дан ным). Такая защита основана на требованиях безопасности, заложенных в соглашениях об Уровне Услуг, контрактных требованиях, законодательстве, правилах работы компании и базовом Уровне Безопасности. При подготовке новой редакции раздела ITIL по предоставлению услуг было решено, что недавно выпущенную книгу по Управлению Информационной Безопасностью не стоит заме нять. Книга ITIL по предоставлению услуг не рассматривает данного предмета, но ссылается на кни гу ITIL по Управлению Информационной Безопасностью.
Глава 4 Управление Инцидентами
4.1. Введение
Задача Процесса Управления Инцидентами является реактивной – уменьшение или исключение отрицательного воздействия (потенциальных) нарушений в предоставлении ИТ-услуг, таким образом обеспечивая наиболее быстрое восстановление работы пользователей. Для выполнения этой задачи производится регистрация, классификация и назначение инцидентов соответствующим группам специалистов, мониторинг хода работ по разрешению инцидентов, решение инцидентов и их закрытие. Так как это требует тесного взаимодействия с пользователями, фокусной точной Процесса управления Инцидентами обычно является функция Service Desk , которая играет роль центра контактов пользователей с "внутренними" коллективами технических служб. Управление Инцидентами является важнейшей основой для работы других процессов ITIL, предоставляя ценную информацию об ошибках в работе ИТ-инфраструктуры.
На рис. 4.1 показан схематичный пример Управления Инцидентами как горизонтальный процесс, охватывающий разные ИТ-отделы и осуществляющий эффективное управление и контроль обработки инцидентов.
Рис. 4.1. Позиционирование Процесса Управления Инцидентами относительно других функций (подразделений) ИТ-организации
4.1.1. Терминология
Инцидент
Библиотека ITIL использует широкое определение термина "инцидент", поэтому почти все обращения пользователей могут регистрироваться и отслеживаться как инциденты.
В книге "Поддержка услуг" библиотеки ITIL дается следующее определение:
Инцидент - это любое событие, не являющееся частью стандартных операций по предоставлению услуги, которое привело или может привести к нарушению или снижению качества этой услуги.
В контексте библиотеки ITIL инцидентами считаются не только ошибки аппаратного или программного обеспечения, но также и Запросы на Обслуживание.
Запрос на обслуживание - это Запрос от Пользователя на поддержку, предоставление информации, консультации или документации, не являющийся сбоем ИТ-инфраструктуры.
Примеры Запросов на Обслуживание:
? вопрос о функционировании ИТ-систем или запрос о предоставлении какой-либо информации;
? запрос о состоянии (статусе) чего-либо в ИТ-инфраструктуре;
? запрос о замене пароля;
? запросы на выполнение пакетных заданий, восстановление или авторизацию пароля;
? получение информации из базы данных.
Для того чтобы можно было отличить "настоящие инциденты" от "инцидентов-Запросов на Обслу живание", рекомендуется присваивать Запросам на Обслуживание специальную категорию. Важно также отметить, что Запрос на Обслуживание это не то же самое, что Запрос на Изменение:
Запрос на Изменение (RFC) – это экранная или бумажная форма, используемая для записи деталь ной информации о предлагаемом Запросе на Изменение какой-либо Конфигурационной Единицы (CI) в ИТ-инфраструктуре или процедуры или какого-либо иного объекта ИТ-инфраструктуры.
Запрос на Изменение RFC считается завершенным после проведения изменения в инфраструктуре, например, замены зарегистрированных компонентов, инсталляции ПК и т. д. Это не инциденты, а изменения.
Степень воздействия , срочность и приоритет
При одновременной обработке нескольких инцидентов необходимо расставлять приоритеты. Обос нованием для назначения приоритета служит уровень важности ошибки для бизнеса и для пользо вателя. На основе диалога с пользователем и в соответствии с положениями Соглашений об Уров нях Услуг (Service Level Agreements – SLAs) Служба Service Desk назначает приоритеты, определя ющие порядок обработки инцидентов. При эскалации инцидентов на вторую, третью или более ли нии поддержки, тот же приоритет должен быть соблюден, но иногда он может быть скорректирован по согласованию со Службой Service Desk.
Конечно, каждый пользователь будет считать, что его инцидент имеет наивысший приоритет, но мнения пользователей часто бывают субъективными. Для объективной оценки приоритета в диало ге с пользователем употребляются следующие критерии:
? степень воздействия инцидента: степень отклонения от нормального уровня предоставления ус луги, выражающаяся в количестве пользователей или бизнес-процессов, подвергшихся воздейст вию инцидента;
? срочность инцидента: приемлемая задержка разрешения инцидента для пользователя или биз нес-процесса.
Приоритет определяется на основе срочности и степени воздействия. Для каждого приоритета опре деляется количество специалистов и объем ресурсов, которые могут быть направлены на разреше ние инцидента. Порядок обработки инцидентов одинакового приоритета может быть определен в соответствии с усилиями, необходимыми для разрешения инцидента. Например, легко разрешаемый инцидент может быть обработан перед инцидентом, требующим больших усилий.
При Управлении Инцидентами существуют способы снижения степени воздействия и срочности, та кие, как переключение системы на резервную конфигурацию, перенаправление очереди печати и др.
Рис. 4.2. Определение степени воздействия, срочности и приоритета
Степень воздействия и срочность также могут сами меняться во времени, например, при росте количества пользователей, подвергшихся воздействию инцидента или в критические моменты времени.