Современные подходы и стандарт управления ИТ-сервисами

Стандарт COBIT

Попытка объединить теоретические знания и опыт управления ИТ, накопленные в последние годы, в рамках единого концептуального подхода была предпринята Ассоциацией аудита и управления информационными системами (Information Systems Audit and Control Association, ISACA ), которая разработала целый ряд взаимосвязанных документов, посвященных разным аспектам управления ИТ.

Начав как сообщество профессиональных аудиторов, ISACA в последние годы значительно расширила границы своих интересов и целевую аудиторию. С ISACA тесно связана другая организация - Институт управления ИТ (IT Governance Institute, ITGI ), который является де-юре автором всех методик, продвигаемых ISACA.

Взаимосвязи трех основных методологий, предлагаемых ISACA, показаны на рис. 2. Это методологии COBIT, Val IT и Risk IT. Центральной в этой картине является методология COBIT, последний релиз которой, COBIT 4.1 был представлен в 2007 году.

Аббревиатура " COBIT" с трудом поддается адекватному переводу на русский язык из-за многозначности английского слова control, широко используемого в терминологии COBIT. Опубликованный русский перевод названия методологии Control Objectives for Information and Related Technology ( COBIT ) - " Цели контроля для информационных и смежных технологий " (COBIT 4.1 рус, 2008) содержательно неточен. Более понятным и передающим смысл документа является следующий перевод: " Цели управления информационными и связанными с ними технологиями ". Возможны и другие варианты.

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

Рис. 2. Взаимосвязь основных методологий ISACA

2.1. Концепция и основные понятия COBIT

По утверждению авторов, COBIT представляет собой совокупность признанных практик (good practices) методов управления ИТ, изложенных с использованием процессного подхода. Акцент в COBIT делается не на детальном описании процессов, а на методах их организации, оценки, измерения и т. п. С точки зрения COBIT, для того, чтобы ИТ удовлетворяли требованиям бизнеса, менеджмент должен позаботиться о том, чтобы разработать и внедрить специальную систему управления ИТ. Методология COBIT является кандидатом на роль такой системы, поскольку она:

· устанавливает связь между ИТ и бизнесом;

· использует общепризнанный процессный подход для описания ИТ-активностей;

· выявляет основные ИТ-ресурсы, которые следует использовать;

· определяет цели управления для рассмотрения их менеджментом.

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

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

Рис. 3. Взаимосвязи бизнес-услуг, ИТ-услуг, целей бизнеса и целей ИТ

Это означает, что в COBIT принята другая, нежели в ITIL, модель взаимодействия бизнеса и ИТ. Однажды определив долгосрочные цели ИТ, связанные с целями бизнеса, ИТ-организация далее развивается как бы автономно до момента, когда эти цели будут скорректированы. Это приводит к появлению в модели процессов COBIT такого процесса, как стратегическое планирование ИТ (см. ниже). В ITIL v.3 подобного процесса нет, а есть только Портфель услуг, наполнение которого в каждый момент времени и определяет все планы развития ИТ.

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

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

В основе системы - совокупность средств и механизмов управления, называемых в оригинале controls. Сюда включаются " политики, процедуры, практики и организационные структуры, сконструированные так, чтобы обеспечить то, что цели бизнеса достигаются, а нежелательные события исключаются или распознаются и корректируются". Точных определений, эталонного перечня средств управления или хотя бы набора примеров книга (COBIT, 2007) не дает.

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

На уровне бизнес-процессов, согласно COBIT, существует две разновидности средств управления процессом: ручные (например, распределение ролей в процессе) и автоматические (разработанные приложения, выполняющие отдельные задачи). Последние в оригинале называются " средствами управления, реализованными в виде приложений" (application controls). Бизнес отвечает за определение и использование как ручных, так и автоматических средств управления. Роль ИТ-организации - только поддерживать автоматические средства управления. В COBIT приводятся следующие примеры автоматических средств управления:

· средства обеспечения законченности транзакции;

· средства обеспечения точности информации;

· средства обеспечения достоверности вводимых данных;

· средства управления правами доступа;

· средства распределения ролей по выполнению транзакций.

Еще одна категория средств управления возникает в связи с взглядом, согласно которому ИТ-организация отвечает за предоставление ИТ-услуг, общих для нескольких бизнес-процессов или даже для всего предприятия. Средства управления деятельностью по предоставлению ИТ-услуг называются общими (general). Примерами общих средств управления ИТ служат, согласно COBIT:

· средства управления разработкой систем;

· средства управления изменениями;

· средства обеспечения информационной безопасности;

· средства обеспечения функционирования компьютеров.

Сами по себе средства управления в COBIT не изучаются, и структура их для COBIT не представляет интереса. Они важны только как объектцелеполагания, т. е. как то, чему можно сопоставить цель. Эти цели называются целями управления (control objectives); они играют фундаментальную роль в концепции COBIT.

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

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

АС1. Подготовка и авторизация исходных данных

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

АС5. Выходные проверки

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

Процессная модель COBIT

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

Процессная область " Планирование и организация (Plan and Organize) " включает следующие процессы:

· разработка стратегического плана развития ИТ;

· определение информационной архитектуры;

· определение направления технологического развития;

· разработка ИТ-процессов, методов организации и взаимосвязей;

· управление ИТ-инвестициями;

· информирование о директивных целях и направлениях развития ИТ;

· управление персоналом;

· управление качеством;

· оценка ИТ-рисков и управление ими;

· управление проектами.

Процессная область " Приобретение и внедрение (Acquire and Implement) " включает процессы:

· выбор программного решения;

· проектирование, разработка и поддержка программного обеспечения;

· приобретение и поддержка технологической инфраструктуры;

· обеспечение использования;

· приобретение ИТ-ресурсов;

· управление изменениями;

· установка и формальная приемка.

Процессная область " Эксплуатация и сопровождение (Deliver and Support)" включает следующие процессы:

· определение уровней обслуживания и управление ими;

· управление услугами сторонних организаций;

· управление производительностью и мощностями;

· обеспечение непрерывности обслуживания;

· обеспечение безопасности систем;

· определение и распределение затрат;

· обучение и подготовка пользователей;

· управление службой поддержки и инцидентами;

· управление конфигурацией;

· управление проблемами;

· управление данными;

· управление физической защитой ИТ-ресурсов;

· управление функционированием.

Процессная область " Мониторинг и оценка5англ. Monitor and Evaluate " включает следующие процессы:

· мониторинг и оценка эффективности ИТ;

· мониторинг и оценка системы управления ИТ;

· обеспечение соответствия внешним требованиям;

· обеспечение корпоративного управления ИТ.

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

В COBIT формулируются так называемые требования к управлению, одинаковые для всех процессов. Эти требования выглядят следующим образом (нумерация сохранена):

PC1. Цели и задачи процесса

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

PC2. Владение процессом

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

PC3. Повторяемость процесса

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

PC4. Роли и ответственности

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

PC5. Политики, планы и процедуры

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

Описание процесса COBIT

Структура описания отдельного процесса в COBIT состоит из следующих четырех разделов:

· краткое описание процесса;

· цели управления процессом;

· входы-выходы процесса, таблица ролей, цели и метрики процесса и его активностей;

· модель зрелости процесса.

Краткое описание дается в виде следующей каскадной схемы:

< назначение процесса>

Управление ИТ-процессом

< имя процесса>

которое удовлетворяет следующим бизнес-требованиям к ИТ:

< наиболее важные ИТ-цели>

за счет того, что

< наиболее важные цели процесса>

и реализуется посредством

< цели активностей>

и измеряется

< ключевые метрики>

Пример краткого описания процесса " Разработка стратегического плана развития ИТ":

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

Управление ИТ-процессом

< Разработка стратегического плана развития ИТ>

которое удовлетворяет следующим бизнес-требованиям к ИТ :

< поддержать или расширить стратегию бизнеса и корпоративные требования и при этом обеспечить необходимую прозрачность в части ожидаемых преимуществ, затрат и рисков>

за счет того, что

< руководство со стороны бизнеса и ИТ включается в процесс перевода бизнес требований в описания предлагаемых услуг и разработку стратегии оказания услуг эффективным и прозрачным способом>

и реализуется посредством

· тесного сотрудничества с менеджерами и высшими руководителями в процессе согласования стратегических ИТ-планов с существующими и будущими потребностями бизнеса;

· понимания текущих возможностей ИТ;

· разработки схемы приоритетов целей бизнеса, которая количественно характеризует требования бизнеса

и измеряется

· процентом целей ИТ в стратегическом плане ИТ, которые поддерживают стратегический бизнес-план;

· процентом ИТ-проектов в портфеле ИТ-проектов, которые непосредственно обусловлены тактическими ИТ-планами;

· задержкой между обновлением стратегических и тактических ИТ-планов.

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

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

Цели управления процессом для каждого процесса свои и даются просто в виде списка. Вот несколько целей управления процессом " Разработка стратегического плана развития ИТ" (нумерация сохранена):

Заключение

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

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

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

Библиотека ITIL

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

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

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

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

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

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

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

Библиотека ITIL

Попытки регламентировать управление ИТ-услугами начались в 80-е годы прошлого века в Великобритании по инициативе правительственного Центрального Агентства по вычислительной технике. В результате была создана, вероятно, самая известная и широко распространенная эталонная модель процессов управления ИТ-услугами, получившая впоследствии название Управление ИТ-услугами ( ITSM1англ. IT Service Management ) и изложенная в нескольких книгах, составивших так называемую библиотеку ITIL2от англ. IT Infrastructure Library. После ряда доработок в 2001 году была опубликована вторая версия ITIL, которая стала де-факто стандартом в области управления ИТ-услугами и послужила теоретической основой ряда программных продуктов, предназначенных для автоматизации управления ИТ-услугами. В качестве примеров можно назвать HP ITSM компании Hewlett-Packard, IT Process Model компании IBM, MOF компании Microsoft. Появление и распространение второй версии ITIL (для краткости - ITIL v.2) привело к созданию некоммерческой организации itSMF (от англ. IT Service Management Forum), которая имеет целью распространение идей ITIL, проведение конференций и форумов, организацию обучения ITIL. Книга (itSMF, 2003) стала фактически общепринятым введением в ITIL для начинающих. Дальнейшее изложение ITIL v.2 опирается на эту книгу.

ITIL v.2

Рис. 8. Процессы управления услугами ITIL v.2

Процессная модель ITIL v.2 (рис. 8) отличается конкретностью и прагматичностью. Процессы подробно описаны в едином шаблоне, включающем не только перечень активностей, но и блок-схемы, описания ролей и ответственностей, критические факторы успеха, метрики и многое другое. Все описания предельно конкретны и не допускают никаких двусмысленных толкований. Вот, например, как выглядит в (itSMF, 2003) описание задачи процесса " Управление инцидентами" (русский перевод, к сожалению, оставляет желать лучшего):

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

Управление Инцидентами является важнейшей основой для работы других процессов ITIL, предоставляя ценную информацию об ошибках в работе ИТ-инфраструктуры".

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

" Инцидент - это любое событие, не являющееся частью стандартных операций по предоставлению услуги, которое привело или может привести к нарушению или снижению качества этой услуги. В контексте библиотеки ITIL инцидентами считаются не только ошибки аппаратного или программного обеспечения, но также и Запросы на Обслуживание ( SR3от англ. Service Request ).

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

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

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

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

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

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

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

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

Запрос на Изменение - это экранная или бумажная форма, используемая для записи детальной информации о предлагаемом Запросе на Изменение какой-либо Конфигурационной в ИТ-инфраструктуре или процедуры или какого-либо иного объекта ИТ-инфраструктуры.

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

Приведенные фрагменты типичны для книги (itSMF, 2003), где описаны основные процессы ITIL v.2. Они демонстрируют, что ИТ-услуги в ITIL v.2 имеют строго инфраструктурный смысл.

Обобщенная модель процессов ITIL v.2 (из (itSMF, 2003)) показана на рис. 9.

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

Процессы описаны словесно, но в полном соответствии с приведенной моделью. Для всех процессов имеются блок-схемы, показывающие порядок выполнения работ и интерфейсы с остальными процессами. Что особенно важно с практической точки зрения, точно определены роли участников процесса. Никаких характеристик зрелости или развитости процессов не приводится, но в главе 2 книги (itSMF, 2003) явно говорится о том, что, используя систему качества, основанную на стандарте ISO 9000-2000, и предложенную эталонную модель процессов ITSM, организация может достичь четвертого уровня зрелости CMM.

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

Помимо эталонной процессной модели из ITIL v.2 в управленческую практику пришло несколько фундаментальных принципов, важность которых полностью подтвердилась со временем:

· перечень услуг, оказываемых ИТ-организацией бизнесу, фиксируется в специальном документе (Соглашении об уровне услуг) и не может быть изменен иначе как в рамках специальной процедуры;

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

· корпоративная оценка ИТ-организации базируется на показателях эффективности процессов оказания услуг. Кроме того, в ITIL v.2 входит процесс Управления финансами, который включает, в частности, деятельность по выставлению счетов за оказанные услуги; это означает, что ITSM позволяет рассматривать деятельность ИТ-организации как бизнес по оказанию ИТ-услуг.

Фактически ITIL v.2 сформировал основы взаимоотношений ИТ-организации и бизнеса. Естественное развитие подхода ITSM состояло в том, чтобы распространить эти принципы с взаимоотношений, связанных с оказанием инфраструктурных услуг, на все взаимодействия ИТ-организации и бизнеса. Шаг в этом направлении был сделан в ITIL v.3.

ITIL v.3

В 2007 г. правительственная британская организация The Office of Government Commerce (http: //www.ogc.gov.uk), издающая ITIL, опубликовала третью версию библиотеки (далее - ITIL v.3), значительно отличающуюся от предыдущих и состоящую из пяти книг ( (OGC, 2007a), (OGC, 2007b), (OGC, 2007c), (OGC, 2007d), (OGC, 2007e)).

Как и ITIL v.2, версия ITIL v.3 представляет собой эталонную модель процессов управления услугами, но система понятий, лежащая в основе модели, претерпела принципиальные изменения. Изменились не процессы и методы, а цели и философия ITIL.

Основным объектом управления в ITIL v.2 была сложившаяся ИТ-инфраструктура. ИТ-организация, управляющая ИТ-инфраструктурой, предоставляла пользователям со стороны бизнеса ИТ-услуги, реализованные на базе этой инфраструктуры. Процессы, связанные с поддержкой и предоставлением услуг, а также бизнес-функция взаимодействия с пользователями (Service Desk) и составляли содержание ITIL v.2.

По существу эта версия ITIL представляла собой набор лучших практик в области управления инфраструктурой и организации взаимодействия ИТ-организации с пользователями. Понятие ИТ-услуги, хотя и играло важную роль в ITIL v.2, определялось на интуитивном уровне. ИТ-услуга составляла предмет формального договора между ИТ-организацией и бизнесом - так называемого Соглашения об уровне услуг ( SLA7англ. SLA - Service Level Agreement ).

12 3 Следующая ⇒