Вы находитесь на странице: 1из 13

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

Лекция 2
Тема лекции: «Концептуальная основа процессов ИТ-службы предприятия»
1. Сервисно-ориентированная  ИТ-служба предприятия.2. Стандартизация управления ИТ-
услугами.  3. ITIL/ITSM - концептуальная основа процессов ИТ-службы. 
1. СЕРВИСНО-ОРИЕНТИРОВАННАЯ  ИТ-СЛУЖБА ПРЕДПРИЯТИЯ.
1.1. Организация и функции сервисно-ориентированной ИТ-службы предприятия. В наши дни
основой успешного бизнеса является бесперебойное функционирование информационных
систем, обеспечивающих конкурентоспособность и прибыльность компании. Информационная
система (ИС) предприятия предназначена для информационной поддержки бизнес-процессов.
Основная задача службы ИС − обеспечение бизнес-процессов информационным обслуживанием
заданного качества с использованием соответствующих  информационных технологий (ИТ).
Поддержка информационных процессов осуществляется посредством ИТ-сервисов с заданными
характеристиками. 
Служба ИС предприятия, как правило, организует свою работу по четырем функциональным
направлениям:
1) планирование и организация;
2) разработка, приобретение и внедрение;
3) предоставление и сопровождение ИТ-сервиса;
4) мониторинг.
1. В рамках направления «Планирование и организация» решаются задачи разработки стратегии в
области ИТ, координации развития ИТ организации, планирования ресурсов службы ИС (бюджет,
человеческие ресурсы, внешние услуги и др.), управления рисками, управления качеством.2.
Основной задачей направления «Разработка, приобретение и внедрение» является внедрение
новых ИС. 3. Функциональное направление «Предоставление и сопровождение сервиса ИТ»
обеспечивает формализацию требований подразделений-заказчиков к ИТ-сервисам,
согласование требований к сервисам с соответствующими ресурсами службы ИС и
предоставление конечным пользователям сервисов ИТ, соответствующих согласованным
требованиям. 4. Основная задача направления «Мониторинг» − аудит процессов службы ИС.
Организационная структура службы ИС зависит от многих факторов. Перечислим основные из
факторов, влияющих на организационную структуру ИТ-службы предприятия: 
1) масштаб службы ИС: более крупные службы ИС обычно имеют более сложную и разветвленную
организацией структуру;
2) отраслевая принадлежность, с которой связано наличие или, напротив, отсутствие
определенных структурных подразделений;
3) распределение организации по территории: наличие территориально удаленных
подразделений и филиалов существенно меняет организационную структуру службы ИС.
Этот перечень открыт, в него входят и другие факторы, например,  состав используемых в
организации ИС.
Для малых предприятий организационная структура службы ИС, описанная в [5], представлена на
рисунке 1. 
Функции планирования в ней выполняются руководителем службы ИС. Именно по этой причине
такая структура пригодна только для службы ИС небольшого размера − в более крупных службах
ИС объем работ по планированию требует обособления отдельных функций
планирования. Рисунок 1. Пример плоской структуры службы ИС.Непосредственно подчиняются
директору ИС управление разработкой, выполняющее функции разработки, приобретения и
внедрения информационных систем, и управление сопровождением, выполняющее функции
предоставления и сопровождения ИТ-сервисов. Организационное разделение разработки и
эксплуатации имеет принципиальное значение. Успешная эксплуатация ИС в течение сколько-
нибудь длительного времени возможна лишь тогда, когда она не требует постоянного
вмешательства разработчика. Это обеспечивается соблюдением существующих методологий
разработки и тестирования ИС, а также надлежащей пользовательской и эксплуатационной
документацией. Тестирование ИС и документации на нее на соответствие требованиям
устойчивой эксплуатации обеспечивается в ходе передачи системы в эксплуатацию. Этот процесс
и определяет важность разделения двух функциональных направлений. Передача ИС от одного
управления службы ИС другому, равноправному первому, обеспечивает всестороннее
тестирование созданной ИС и документации на нее. Напротив, внутри одного управления
передача в эксплуатацию осуществляется обычно формально, с учетом возможности
последующих доработок. Таким образом, во втором случае качество эксплуатируемой ИС обычно
оказывается нижеВ рамках процесса разработки одна и та же группа − проектная команда,
подчиненная одному руководителю, − должна последовательно выполнить все функции процесса
разработки применительно к определенной ИС. Следовательно, распределение функций
разработки по различным подразделениям не имеет смысла. Напротив, имеет смысл выделить
различные проектные группы для различных видов ИС, требующих от сотрудников различных
знаний и навыков. В результате в нашем примере выделены два отдела разработки − отдел
офисных систем и отдел распределенных систем. 
ПРИМЕР.
Например, офисные системы представляют собой разработки в среде пакета MS Office,
распределенные системы − многопользовательские системы, специализированные для
выполнения отдельных задач.  В малых организациях типичным примером таких задач и
соответственно ИС являются бухгалтерские системы. 
Отдел офисных систем решает задачи «малой автоматизации» задач пользователей в среде MS
Office. Отдел распределенных систем занимается внедрением бухгалтерской системы, а после
того как внедрение завершено, расширением ее функциональности − внедрением
дополнительных модулей, написанием отчетов и других программ в среде данной
распределенной системы. Наконец, в штате управления разработкой необходим хотя бы один
менеджер проектов. В простейшем случае им может быть руководитель управления разработкой,
однако совмещение этих двух позиций может стать узким местом проектов этого управления.
Таким образом, директор ИС должен отслеживать ситуацию с управлением проектами и при
необходимости расширить управление разработкой за счет одного или нескольких менеджеров
проектов.
В управлении сопровождением выделяют группы специалистов сходной квалификационной базы.
Отделами, состоящими из сотрудников сходной квалификации, проще управлять, поскольку
однородность упрощает найм персонала, диспетчирование работ, бюджетирование и др.
Типичный набор отделов в управлении сопровождением в плоской структуре  включает отдел ЛВС
(локальной вычислительной сети), отдел распределенных систем, отдел связи и
телекоммуникаций, отдел офисных приложений. Первый отдел осуществляет поддержку
локальной сети, включая сервер и его ОС, второй − поддержку распределенных систем, например
бухгалтерской, третий − связь, телефонизацию и доступ в Интернет, четвертый − поддержку
оборудования рабочих мест − компьютеров, принтеров и т.д., а также офисных приложений.
Функции мониторинга в плоской структуре выполняет отдел мониторинга (Service Desk),
непосредственно подчиненный директору ИС. В этот отдел поступают сообщения пользователей
об инцидентах, он же сообщает об инциденте соответствующим отделам службы сопровождения
и контролирует ход работ по разрешению инцидента. Наконец, в этом отделе накапливается
большой объем статистики инцидентов и времени их разрешения. Функции мониторинга более
высокого уровня − контроль планов работ, графиков проектов, бюджета службы ИС в целом и
отдельных ее подразделений − выполняет директор ИС.
Увеличение размера организации и объема работ службы ИС ведет к усложнению её
организационной структуры. В этом случае могут применяться развернутые и дивизиональные
структуры службы ИС.
Функциональная модель управления и основанная на ней организационная структура службы ИС
длительное время представляли собой основной и единственный подход к управлению в этой
области. Однако со временем выявился ряд ограничений функционального подхода, снижавших
эффективность управления службой ИС. Функции службы ИС должны обеспечивать создание
конечного продукта − ИТ-сервисов, поддерживающих выполнение определенных бизнес-
процессов.
Функциональность ИТ-сервиса затрагивает большое количество функций службы ИС. На этапе
планирования ИТ-сервиса функциональность согласовывается со стратегией, стандартами и
планами в рамках стратегических функций службы ИС: контролируется соответствие создаваемого
сервиса ИТ-стратегии предприятия, принятым стандартам и нормам ИТ-службы, а также наличие
средств в бюджете предприятия. 
На этапе разработки и внедрения функциональность ИТ-сервиса обеспечивается всеми
функциями направления разработки и внедрения. 
Наконец, на этапе эксплуатации ИТ-сервиса функциональность обеспечивается управлением
данными, оборудованием и системным программным обеспечением и поддержкой конечных
пользователей. Соответствующие функции отдела сопровождения и эксплуатации обеспечивают
учет связанных с сопровождением ИТ-сервиса расходов, а функции отдела мониторинга −
соблюдение условий соглашений между заказчиком и службой ИС, с одной стороны, и службой
ИС и внешними поставщиками − с другой.
Время обслуживания, доступность,  надежность и производительность ИТ-сервиса определяется в
ходе согласования требований к ИТ-сервису с заказчиком и далее контролируется функциями
мониторинга. Обеспечиваются эти параметры функциями поддержки конечных пользователей
(устранение возникших сбоев) и управления данными, оборудованием и системным ПО
(предотвращение возникновения сбоев и/или снижение их количества). Данные по
производительности операций, существенных для конечного пользователя, могут быть получены
на основании статистики использования прикладных систем.
Конфиденциальность ИТ-сервиса на этапе планирования формулируются в рамках функции
определения политики безопасности отдельных сервисов. На этапе создания ИТ-сервиса в рамках
функций разработки, приобретения и внедрения сервиса реализуется необходимая
инфраструктура безопасности − разделение полномочий на доступ к операциям и документам,
присвоение прав пользователям, шифрование данных и т.д. Наконец, на этапе эксплуатации
сервиса осуществляются обучение пользователей и контроль выполнения требований
безопасности на рабочих местах конечных пользователей.
Масштаб ИТ-сервиса определяется на этапе планирования сервиса в рамках функции
планирования сервиса ИТ. Если некие сервисы ИТ реализуются совместно в рамках общего
проекта, эти сервисы должны планироваться совместно. Обеспечение доступа к ИТ-сервису на
всех серверах и рабочих местах реализуется в рамках функций приобретения, разработки и
внедрения. Изменения масштаба сервиса контролируются в рамках функций планирования и
организации.
Цена ИТ-сервиса определяется в процессе планирования сервиса. На этапе разработки и
внедрения ИТ-сервиса контролируется выполнение бюджета соответствующего проекта и
уточняется сумма первоначальных затрат на приобретение и/или разработку и внедрение. На
этапе эксплуатации контролируется величина текущих затрат на сервис и их соответствие бюджету
организации.
Таким образом, между функциями службы ИС и параметрами ИТ-сервиса нет прямого и
однозначного соответствия. Качество ИТ-сервиса в целом и каждый параметр ИТ-сервиса в
частности определяются несколькими функциями ИТ. Одна и та же функция службы также может
относиться к нескольким ИТ-сервисам  или даже ко всем ИТ-сервисам, существующим в
организации. Это обстоятельство создает для управления службой ИС, организованной по чисто
функциональному принципу, целый ряд проблем.
1. Во-первых, обеспечение конечного результата − качества ИТ-сервиса − требует координации
различных функций службы ИС. В ряде случаев эту координацию может осуществить
вышестоящий руководитель. Однако многие задачи по такой координации требуют полномочий
высокого уровня, вплоть до уровня директора ИТ. В результате руководители высокого уровня
оказываются перегруженными большим потоком задач, не имеющих отношения к их постоянной
деятельности и непосредственным обязанностям.
2. Во-вторых, управление подразумевает ответственность, и коль скоро параметры сервиса
определяют качество последнего, следует назначить лиц, ответственных за эти параметры. При
этом сфера ответственности не должна превышать полномочий ответственного лица. Из
проведенного анализа прямо следует, что в целом содержание, доступность, надежность,
производительность и конфиденциальность ИТ-сервиса находятся исключительно в сфере
полномочий директора ИТ. Такой объем обязанностей ИТ-директора возможен в плоской
структуре службы ИС, но абсолютно нереалистичен для развернутой или дивизиональной
структуры. В результате лицо, ответственное за качество ИТ-сервиса, при функциональной
организации службы ИС отсутствует. 
3. В-третьих, проблемой является «точка контакта» − телефон и/или адрес электронной почты, по
которому следует обращаться в случае необходимости. Наличие такой «точки контакта» особенно
удобно в случае возникновения у пользователя потребности в новом или измененном ИТ-сервисе,
а также при необходимости сообщить о сбое. При этом «точка контакта» может быть
использована не только для регистрации запроса пользователя, но и для обработки его −
назначения запроса специалисту, контроля хода выполнения работ, информации пользователя.
Однако в функциональной организации эту дополнительную обработку организовать
затруднительно. Специалисты, обрабатывающие запрос пользователя, не находятся в подчинении
службы мониторинга (Service Desk) и не ответственны перед этой службой.
Таким образом, функциональная организация обеспечивает лишь текущую деятельность службы
ИС, а не решение всех необходимых управленческих задач. 
С точки зрения обеспечения конечного результата − ИТ-сервиса необходимого качества −
основными проблемами являются:
- координация функций;
- трудности обеспечения ответственности;
- трудности обеспечения единой «точки контакта». 
Эти трудности успешно преодолеваются при процессном подходе к управлению службой
ИС.Процесс подразумевает наличие цели, критерия результата, ресурсов и определенной
последовательности работ (т.е. шагов процесса). 
Применительно к процессам ИТ-службы целью является предоставление заказчику ИТ-сервиса
приемлемого уровня качества. Эта общая задача может быть разделена на две более частных: 
1) определение и согласование параметров ИТ-сервиса;2) обеспечение соответствия фактических
параметров ИТ-сервиса достигнутым соглашениям. 
Каждая из этих целей, в свою очередь, распадается на несколько целей следующего порядка,
каждой из которых соответствует свой процесс.
Управление процессами предполагает следующие шаги:
Шаг 1. Определение цели процесса и показателей достижения этой цели (количественных или
качественных). 
Шаг 2. Назначение ответственного за процесс, задачей которого является достижение цели
процесса. 
Шаг 3. Регламентация процесса в целом и составляющих его работ. 
Шаг 4. При необходимости − автоматизация процесса посредством инструментальных средств,
разработанных в самой организации либо закупленных извне.
Проблемы ответственности за результат процесса и координации разрешается в явном виде
посредством назначения ответственного лица – менеджера процесса. Проблема единой «точки
контакта» также вполне разрешима в рамках регламента процесса, обязательного для всех
сотрудников службы ИС независимо от их функционального подчинения.Управление процессами
изменяет лишь управленческие функции службы ИС, не затрагивая функции собственно
разработки и сопровождения ИТ-сервисов. Изменения состоят в систематическом
целенаправленном решении задач координации функций в ходе выполнения процессов службы
ИС. Для этого достаточно формализовать соответствующий процесс, т.е. назначить менеджера
процесса, определить роли участников процесса и установить правила его выполнения, т.е.
последовательность выполнения операций процесса, обязанности в рамках ролей, правила
эскалации и т.д.Как следствие переход к процессной модели управления обычно не требует ни
дополнительного персонала, ни изменений в организационной структуре. Участники процесса
выполняют свои должностные обязанности в рамках существующей организационной структуры;
часть этих обязанностей, относящаяся к данному процессу, формализована в виде ролей
процесса. Если все процессы службы ИС формализованы, то совокупность ролей совпадает с
должностными обязанностями сотрудника (рисунок 2).  Рисунок 2. Процессы, функции, роли в
процессной модели управления.В такой системе менеджер процесса является начальником без
подчиненных: он координирует деятельность не подчиненных ему сотрудников, относящихся к
различным подразделениям существующей организационной структуры. Сам менеджер процесса
тоже имеет должность в рамках существующей организационной структуры.Использование
процессов в рамках существующей функциональной структуры весьма удобно. В ходе работы по
этой схеме процессная модель и функциональная структура организации взаимодействуют между
собой и усиливают преимущества друг друга. Совместное использование обеих моделей также
упрощает внедрение процессной модели. Процессная модель влияет не на полномочия
функциональных менеджеров, а на формы осуществления этих полномочий. Процессные
менеджеры принимают на себя задачу координации функций, которая в чисто функциональной
модели решается на излишне высоком уровне.
Переход к процессной модели можно осуществить двумя путями: 
Первый путь состоит в формализации опыта данной организации.  
Второй путь предполагает использование передового опыта управления службой ИС, который
реализован в типовых моделях бизнес-процессов этой службы.  На сегодняшний день общей
методологической основой таких моделей является подход ITIL/ITSM, основанный на сборе и
систематизации передовой практики управления службой ИС в течение последних 20 лет. В
отличие от более традиционного функционального подхода к организации ИТ-службы, ITSM
рекомендует сосредоточиться на клиенте и его потребностях, на ИТ-услугах, предоставляемых
пользователю информационными технологиями, а не на них самих. При этом процессная
организация предоставления услуг и наличие заранее оговоренных уровней параметров
эффективности позволяет ИТ-службе предоставлять качественные ИТ-услуги, измерять и улучшать
их качество.
Использование типовых моделей бизнес-процессов службы ИС имеет целый ряд
преимуществ. Во-первых, типовая модель представляет в концентрированном виде опыт
управления службой ИС в тысячах и даже десятках тысяч компаний. Соответственно, отказ от
использования этого массива знаний по меньшей мере нецелесообразен. Во-вторых, переход к
процессной модели управления для всех задач службы ИС одновременно, в рамках одного
проекта маловероятен. В этом случае процессная модель дает менеджеру образ будущего,
который становится ориентиром в ходе отдельных шагов внедрения. В-третьих, типовая модель
процессов службы ИС всегда опирается на некую систему понятий, на некий язык. Использование
этого языка значительно облегчает достижение взаимопонимания участников процесса. В-
четвертых, типовая модель процессов поддержана разработчиками программного обеспечения
автоматизации управления службой ИС и инфраструктурой ИТ. В результате программное
обеспечение реализует именно эти процессы. Реализация собственных процессов потребует
разработки собственного ПО. Наконец, стандартная модель процессов обычно внедряется во
многих организациях. В результате образуется сообщество пользователей, которое является
ценным источником информации по внедрению модели.В настоящее время ИТ-служба
предприятия становится полноправным участником бизнеса, выступая в роли поставщика
определенных услуг для бизнес-подразделений, а отношения между ними формализуются как
отношения «поставщик услуг – потребитель услуг». Бизнес-подразделение формулирует свои
требования к необходимому спектру услуг и их качеству, руководство предприятия определяет
объем финансирования для выполнения этих требований, а подразделения ИТ-службы
поддерживают и развивают информационную инфраструктуру предприятия таким образом, чтобы
она была в состоянии обеспечить запрошенную услугу с заданным качеством. 
1.2. Сервис-ориентированная архитектура (SOA) как основа ссылочной модели архитектуры
предприятия. 
Под сервис-ориентированной архитектурой (Service-oriented architecture - SOA) понимается
подход к проектированию прикладных информационных систем, который руководствуется
следующими принципами:
-  явное отделение бизнес-логики прикладной системы от логики презентации информации;
- реализация бизнес-логики прикладной системы в виде некоторого количества программных
модулей (сервисов), которые доступны извне (пользователям и другим модулям), чаще всего в
режиме «запрос-ответ» через четко определенные формальные интерфейсы доступа;
- при этом «потребитель услуги», который может быть прикладной системой или другим
сервисом, имеет возможность вызвать сервис через интерфейсы, используя соответствующие
коммуникационные механизмы.
Интерфейсы сами по себе не зависят от используемых аппаратных платформ, операционных
систем или языков программирования, используемых для разработки этих приложений. Это
позволяет отдельным сервисам взаимодействовать между собой одним и тем же стандартным,
но в то же время универсальным способом. Такая особенность использования интерфейса,
независимого от окружения и платформы, получила название модели «слабой связи». Ее
очевидным преимуществом является повышенная гибкость и адаптируемость, поскольку замена
или модернизация одной из компонент системы не сказывается на остальных.
Ориентация на сервисную архитектуру позволяет построить комплексную ссылочную модель
архитектуры предприятия (рисунок 3), которая в единой манере описывает как бизнес, так и ИТ и
состоит из следующих основных компонент:
- презентационный уровень описывает интерфейсные сервисы для взаимодействия
пользователей с информационной системой, включая корпоративные и публичные порталы,
доступ с мобильных устройств, а также различные преобразования информации при
взаимодействии с внешними системами и устройствами;
- на уровне бизнес-сервисов формируются модели, и осуществляется управление выполнением
бизнес-процессов предприятия  с использованием специализированных средств (типа BPEL - англ.
Business Process Execution Language язык на основе  XML для формального описания бизнес-
процессов и протоколов их взаимодействия между собой), а также координация
автоматизированных и «ручных» операций; 
- интеграционные сервисы обеспечивают взаимодействие между приложениями, которое может
быть реализовано, в частности, с использованием средств обмена сообщениями или в рамках
единой среды исполнения, такой как сервер приложений J2EE.
(Java Platform, Enterprise Edition – набор спецификаций и соответствующей документации и для
языка Java, описывающей архитектуру серверной платформы для задач средних и крупных
предприятий);
- сервисы уровня данных реализуют средства извлечения  и повторного использования данных из
и СУБД и приложений. Явное выделение такого уровня позволяет изолировать вышестоящие
компоненты архитектуры от изменений в технологиях (например , смены вендора или версии
продукта), а также обеспечить единый унифицированный подход  к выполнению операций с
данными; 
- уровень инфраструктуры, приложений и СУБД является как бы основой  для всей  структуры, и
именно здесь концентрируются я основные инвестиции в ИТ. 
Рисунок 3. Ссылочная модель  сервис-ориентированной архитектуры предприятия.
Взаимодействие между этими уровнями, однако, осуществляется не напрямую, а через сервисы,
выделенные на уровень обработки событий. Сервисы этой компоненты архитектуры
обеспечивают сбор данных о событиях в масштабе всего предприятия, необходимое
преобразование и маршрутизацию этих данных между разными уровнями, а также «обратную
связь» между сервисами каждого отдельного уровня.
Для задач электронного бизнеса соответствующая функциональность SOA реализуется на уровне
web-сервисов (служб). 
Под web-сервисами понимаются программные системы, которые используют XML в качестве
формата данных, стандарты Web Services Description Language (WSDL) для описания своих
интерфейсов, Simple Object Access Protocol (SOAP) для описания формата принимаемых и
посылаемых сообщений и стандарт Universal Description, Discovery and Integration (UDDI) для
создания каталогов доступных сервисов.
При этом web-сервисы являются технологическими спецификациями, в то время как сервис-
ориентированная архитектура (SOA) является принципом проектирования архитектуры
программных систем.
Современные организации по всему миру активно внедряют как внутренние, так и внешние
приложения в соответствии с сервисно-ориентированным подходом. С ростом количества
используемых web-сервисов в организации, наряду с преимуществами от сервисного подхода,
растет и потребность управлении непосредственно web-сервисами. 
2. СТАНДАРТИЗАЦИЯ УПРАВЛЕНИЯ ИТ-УСЛУГАМИ. 
ITIL (IT Infrastructure Library) – библиотека, описывающая лучшие из применяемых на практике
способов организации работы подразделений или компаний, занимающихся предоставлением
услуг в области информационных технологий.
Ядро ITIL (V3) состоит из пяти книг, описывающих жизненный цикл услуг. От начального
определения и анализа требований бизнеса к услуге   (книги «Service Strategy» – «Стратегия
сервиса» и «Service Design» – «Проектирование сервиса»),  через подготовку и встраивание
сервиса в рабочую среду (книга «Service Transition» – «Внедрение сервиса»),  к эксплуатации в
реальных условиях («Service Operation» – «Эксплуатация сервиса») и усовершенствованию сервиса
(«Continual Service Improvement» – «Непрерывное улучшение сервиса»). Третья версия также
включает книгу «Introduction to ITIL Service Management Practices» («Введение в практику
управления сервисами»). 
CobiT (Control Objectives for Information and Related Technology – Задачи информационных и
смежных технологий) представляет собой пакет открытых документов – около 40 международных
и национальных стандартов и руководств в области управления ИТ, аудита и ИТ-безопасности.
Создатели этого пакета стандартов провели анализ и оценку и объединили лучшее из
международных технических стандартов, стандартов управления качеством, аудиторской
деятельности, а также из практических требований и опыта — всего того, что,  так или иначе,
имело отношение к целям управления. Задача CobiT заключается в ликвидации разрыва между
руководством компании с его видением бизнес-целей и ИТ-подразделением, осуществляющим
поддержку информационной инфраструктуры, которая должна способствовать достижению этих
целей. В CobiT детально описаны цели и принципы управления, объекты управления, четко
определены все ИТ-процессы (задачи), протекающие в компании, и требования к ним, описан
возможный инструментарий для их реализации, а также приведены практические рекомендации
по управлению ИТ-безопасностью. Кроме того, CobiT вводит целый ряд показателей (метрик) для
оценки эффективности реализации системы управления ИТ, которые часто используются
аудиторами ИТ-систем. В их число входят показатели качества и стоимости обработки
информации, характеристики ее доставки получателю, показатели, относящиеся к субъективным
аспектам обработки информации (например, стиль, удобство интерфейсов). В этом стандарте
оцениваются показатели соответствия компьютерной ИТ-системы принятым стандартам и
требованиям, достоверность обрабатываемой в системе информации, ее действенность,
общепринятые показатели информационной безопасности. В CobiT вводится понятие модели
зрелости процесса, показывающей, как процесс может быть улучшен. Первая версия стандарта
была выпущена в 1996 г. Организацией аудита и контроля информационных систем (Information
Systems Audit and Control Foundation – ISACF). Она включала концептуальное ядро, определяющее
набор основополагающих принципов и понятий в области управления ИТ, описание задач
управления и руководство по аудиту. 
Вторая, переработанная версия CobiT, была опубликована в 1998 году. 
Третья версия CobiT выпущена в 2000 году Институтом управления информационными
технологиями (IT Governance Institute), учрежденным Ассоциацией аудита и контроля
информационных систем (Information Systems Audit and Control Association – ISACA) совместно с
Организацией аудита и контроля информационных систем (Information Systems Audit and Control
Foundation – ISACF)  с целью развития и популяризации принципов управления ИТ (в настоящее
время названный институт является основным разработчиком CobiT). Проект подготовки третьей
версии CobiT включал разработку принципов управления и переработку второй версии с
использованием новых и пересмотренных международных источников. Кроме того, концепция
CobiT была пересмотрена и расширена с тем, чтобы предусмотреть усиленный административный
контроль, ввести и развить управление ИТ-услугами. Новейшая версия CobiT 5 была опубликована
в апреле 2012 г. Она основана на более чем 15-летнем опыте практического использования и
применения CobiT многими предприятиями и сообществами специалистов в области бизнеса, ИТ,
управления рисками и безопасностью, а также контроля качества. Несмотря на разницу в областях
применения, ITIL часто упоминается в одном ряду с COBIT как популярные инструменты
управления ИТ. Однако в то время, как COBIT является более высокоуровневым руководством,
концентрирующемся в основном на корпоративном управлении ИТ и ИТ-аудите, ITIL представляет
собой сборник лучших практик построения/организации ИТ-процессов.
Есть ли взаимосвязь или взаимозависимость между CobiT и ITIL? Стандарт CobiT и библиотека
стандартов ITIL не являются противоречащими друг другу подходами, они дополняют друг друга,
охватывая разные сферы деятельности и разные уровни управления. ITIL — библиотека лучшего
практического опыта в части управления ИТ-услугами, а CobiT специализируется и на управлении,
и на аудите ИТ. Необходимо отметить, что и к процессам ITIL могут быть применены принципы
контроля и управления CobiT. 
CobiT помогает понять, что следует делать для решения поставленной задачи, а ITIL показывает,
как этого достичь. Другими словами, оба стандарта оказываются более полезными именно тогда,
когда используются вместе, а не по отдельности.  Библиотека ITIL положила начало росту новой
индустрии. На её базе некоторые коммерческие компании разработали свои структурированные
подходы к управлению ИТ-услугами.  Среди них HP ITSM Reference Model компании Hewlett-
Packard, IT Process Model компании IBM, MOF компании Microsoft и др. MOF (Microsoft Operations
Framework) – система стандартов управления ИТ от компании Microsoft (США). Стандарты
Microsoft охватывают несколько предметных областей. Одной из них является деятельность по
поддержке информационной системы, внедренной на предприятии, которую и описывает
стандарт MOF. MOF состоит из набора статей, руководств, обучающих курсов и включает три
основные модели: модель процессов (MOF Process Model), модель команды (MOF Team Model),
модель управления рисками (MOF Risk Model). Действующая версия стандарта была представлена
разработчиками в 2008 году. Общая похожесть этой системы стандартов MOF на ITIL и ориентация
на продукты Microsoft делает стандарт MOF менее используемым относительно ITIL. Если
сравнивать библиотеку ITIL с системой стандартов MOF, то MOF является некоторым расширением
процессов, описанных в книгах «Предоставление ИТ-услуг» и «Поддержка ИТ-услуг» библиотеки
ITIL, однако расширение MOF в данном направлении не вносит большой новизны. Стандарт MOF
помимо процессной модели содержит ролевую структуру для распределения полномочий и
ответственности между сотрудниками ИТ – модель команды (MOF Team Model). В остальном,
процессы, включенные в ITIL и MOF, имеют одинаковые наименования и описания, а значит и
преимущества от их использования полностью идентичны. HP ITSM Reference Model – это
корпоративная модель стандарта, которая была разработана компанией HP (США) на основе и в
полном соответствии с библиотекой ITIL. Ее первый вариант был опубликован в сентябре 1997 г.,
следующий – в январе 2000 г. Действующая версия HP ITSM 3.0 выпущена в июне 2003 г.
Фактически она является переработкой ITIL с учетом точки зрения компании HP, и перечень
процессов в обеих моделях одинаковый. IT Process Model  – это стандарт, который был предложен
компанией IBM (США) в конце 70-х гг. прошлого века для решения задач управления
компьютерными системами. Была создана архитектура ISMA (Information Systems Management
Architecture) и концепция IT Process Model, возникшая из ISMA и принятая к использованию
компанией IBM. Этот подход отличается от ITIL не только по способу деления процессов, но и по
ряду терминологических моментов. Фактически IT Process Model – это стандарт, содержащий
описание 41 процесса, собранных в восемь групп по числу основных факторов, влияющих на успех
ИТ-проектов: взаимодействие с клиентами; обеспечение управленческих систем корпоративной
информацией; управление ИТ с точки зрения бизнеса; подготовка решений; развертывание
решений; предоставление услуг и управление изменениями; поддержка ИТ-услуг и решений;
управление ИТ-ресурсами и инфраструктурой. ISO/IEC 20000 «Information Technology. Service
Management» – первый международный стандарт в области управления качеством ИТ-услуг,
вобравший в себя с незначительными изменениями большинство основных принципов и
процессов ITIL. Стандарт впервые был принят в 2005 году и состоял из двух частей. В 2010 г. были
утверждёны российские ГОСТ Р ИСО/МЭК 20000-1-2010 и ГОСТ Р ИСО/МЭК 20000-2-2010
«Информационная технология. Менеджмент услуг» (также в двух частях). Отечественный ГОСТ
разработан методом аутентичного перевода оригинального текста ISO 20000, т. е. с точки зрения
«буквы закона» эти стандарты одинаковы и равноценны. 
В 2011 году стандарт ISO 20000 получил обновление – вышла новая редакция ISO/IEC 20000:2011
(см.: официальный сайт itSMF России:  http://www.itsmforum.ru/reference/ISO20000). 
В настоящее время производится сертификация ИТ-подразделений на соответствие сервис-
ориентированному и процессному подходу в области управления ИТ с использованием данного
стандарта. 
Если делать вывод о применимости рассмотренных стандартов в области информационных
технологий, то можно с уверенностью сказать, что все они содержат «зерно истины», поэтому
применение их в совокупности наиболее предпочтительно, поскольку в определенных областях
они имеют новшества относительно друг друга. Таким образом, одна и та же компания может
одновременно использовать стандарты всех уровней для организации своей деятельности. Все
рассмотренные стандарты, рекомендации и требования, безусловно, хороши, но они основаны,
хоть и на лучших, но зарубежных практиках.
На таком фоне развивались процессы управления корпоративным контентом и ИТ-услугами на
предприятиях. 
Для содействия реализации подхода к управлению ИТ-услугами используется серия документов
ITIL. 
В отличие от более традиционного технологического подхода, ITSM рекомендует сосредоточиться
на клиенте и его потребностях, на услугах, предоставляемых пользователю информационными
технологиями, а не на самих технологиях. При этом процессная организация предоставления услуг
и наличие заранее оговоренных в соглашениях об уровне услуг параметров эффективности (KPI)
позволяет ИТ-отделам предоставлять качественные услуги, измерять и улучшать их качество.
Важным моментом при изложении принципов ITSM является системность. При изложении
каждого составного элемента ITSM (управление инцидентами, управление конфигурациями,
управление безопасностью и т. д.) в обязательном порядке прослеживается его взаимосвязь и
координация с остальными элементами (службами, процессами) и при этом даются необходимые
практические рекомендации.
ITIL не является конкретным алгоритмом или руководством к действию, но она описывает
передовой опыт (best practices) и предлагает рекомендации по организации процессного подхода
и управления качеством предоставления услуг. Это позволяет оторваться от особенностей данного
конкретного предприятия в данной конкретной отрасли. Вместе с тем, несмотря на определённую
абстрактность, ITIL всячески нацелено на практическое использование. В каждом разделе
библиотеки приводятся ключевые факторы успеха внедрения того или иного процесса,
практические рекомендации при этом превалируют над чисто теоретическими рассуждениями.
3. ITIL/ITSM - КОНЦЕПТУАЛЬНАЯ ОСНОВА ПРОЦЕССОВ ИТ-СЛУЖБЫ. 
Отражением трансформации роли и места ИТ-службы в структуре предприятий является
концепция и модель управления качеством информационных услуг (Information Technology Service
Management – ITSM, управление ИТ-услугами). Бизнес-процессы сегодня неразделимы с
программными приложениями, техническими ресурсами и деятельностью персонала ИТ-служб,
поэтому качество работы ИТ-служб предприятия становится важнейшим фактором,
определяющим эффективность деятельности предприятия в целом.Модель ITSM является
открытой для изменения со стороны пользователей и описывает совокупность процессов службы
ИС. Это позволяет настраивать процессы ITSM для конкретного применения. Существует большое
количество инструментальных средств, реализующих модели процессов ITSM, разработанных
компаниями-консультантами и производителями программного обеспечения управления
инфраструктурой ИТ. Модель ITSM не дает ИТ-менеджеру службы ИС однозначных рекомендаций
как конкретно строить систему управления информационной инфраструктурой предприятия. В то
же время концепция ITSM содержит модель типовых процессов службы ИС, понятийный аппарат,
на основе которых целесообразно строить модели процессов для ИТ-службы. Модель ITSM,
разработанная в рамках проекта ITIL (IT Infrastructure Library - библиотека инфраструктуры
информационных технологий, произносится как «айти?л»), описывающая процессный подход к
предоставлению и поддержке ИТ-услуг. Данная модель получила наибольшую известность в силу
того, что предоставление и поддержка ИТ-услуг является первичной задачей ИТ-службы
предприятия. Множество частных и государственных компаний в разных странах мира, включая и
Россию, добились значительных успехов в повышении качества ИТ-сервисов, следуя изложенным
в ITIL рекомендациям и принципам. В настоящее время ITIL становится стандартом де-факто для
ИТ.
3.1. Основные положения ITIL. 
ITIL исходит из того, что деятельность ИТ-службы фокусируется на обеспечении основной бизнес-
деятельности компании полным набором информационных сервисов. Качество сервиса при этом
является величиной измеряемой и фиксируется в Соглашениях об уровне предоставления услуг
SLA, в которых также указываются все параметры поставляемых услуг.
В настоящее время существует несколько версий библиотеки ITIL. Третья, выпущенная в 2007 году,
редакция ITIL (с последующим обновлением в 2011) включила в себя пять основных книг,
поддерживающих концепцию «жизненного цикла услуг»:
1. Стратегия услуг (Service Strategy).
2. Проектирование услуг (Service Design).
3. Преобразование услуг (Service Transition).
4. Эксплуатация услуг (Service Operation).
5. Постоянное улучшение услуг (Continual Service Improvement).
Приведем ниже списки процессов каждой из книг ITIL (v3) (Service Strategy, Service Design, Service
Transition, Service Operation, Continual Service Improvement)   и отдельно выделим 10 процессов,
которые выделялись в качестве основных в предыдущей версии ITIL (v2) и до сих пор наиболее
часто упоминаемые многими источниками по всему миру.
1. Книга ITIL «Стратегия услуг»  («Service Strategy») ? Бизнес-ориентация в управлении ИТ. 
Основные процессы: 
- Формирование стратегии. 
- Управление финансами. 
- Управление портфелем услуг. 
-  Управление требованиями. 
2. Книга ITIL «Проектирование услуг» («Service Design») ? Построение поддерживающей стратегию
системы управления. 
Основные процессы:
- Управление каталогом услуг.
- Управление уровнем сервиса.
- Управление доступностью.
- Управление мощностями. - Управление непрерывностью.
- Управление безопасностью.
- Управление поставщиками.
3. Книга ITIL «Преобразование/внедрение услуг» («Service Transition») ? Трансформация системы
управления за счет сочетания человеческих ресурсов, процессов и технологий.
Основные процессы:
- Планирование и поддержка развития.
- Управление изменениями. 
- Управление активами сервисов и конфигурациями. 
- Управление релизами и развертыванием. 
- Отладка и тестирование сервисов. 
- Оценка. 
- Управление знаниями. 
4. Книга ITIL «Эксплуатация услуг»  («Service Operation») ? Операционная деятельность. 
Основные процессы:
- Управление событиями. 
- Управление инцидентами. 
- Выполнение запросов. 
- Управление проблемами.  
- Управление доступом. 
5. Книга ITIL «Постоянное улучшение услуг»  («Continual Service Improvement») ?
Совершенствование ИТ-процессов. 
Основные процессы:
- Совершенствование сервисов.
- Измерение сервисов.
- Подготовка отчетности о сервисах. 
Подробнее опишем следующие десять процессов из вышеприведенных процессов.
Управление инцидентами (Incident management).
Регистрация и реагирование на любые события и обращения пользователей, которые требуют
реагирования. Как правило, эта функция возлагается на службу поддержки, которая должна
разрешать основные вопросы в сфере своих компетенций и в случае необходимости привлекать
смежные службы и другие группы / линии поддержки для скорейшего закрытия инцидентов.
Управление проблемами (Problem management).
Поиск, анализ, мониторинг проблем, вызывающих инциденты, с целью минимизации их
негативного влияния на предоставление услуг, а также предотвращения последующих
инцидентов. В качестве таких проактивных мер проводятся анализ трендов, анализ инцидентов в
рамках определенной тематики или происходящих в определенной организационной единице.
Важно перейти от множества проблем (как неизвестных причин появления инцидентов) к
множеству «известных ошибок» (как причин появления инцидентов, которые уже определены и
пути решения которых уже найдены).
Управление конфигурациями (Configuration management).
Хранение информации о логической модели ИТ-инфраструктуры компании: существующих
конфигурационных компонентах и их взаимосвязях. Именно этим процессом поддерживается
создание базы конфигурационных элементов CMDB, ее планирование и поддержка.
Управление изменениями (Change management).
Координация производимых изменений ИТ-сервисов и поддерживающих ее ресурсов и
минимизация рисков возникновения вызванных изменениями инцидентов. Изменением
признается событие, приводящее к смене статуса одного или более конфигурационных
элементов. Важно, что изменение должно быть санкционировано руководством, быть
эффективным с точки зрения стоимости и влияния на бизнес-процессы. В ITIL используется
распространенный термин запроса на изменение (request for change, RFC), которым обозначается
документ с описанием деталей необходимых изменений, широко использующийся и в сфере
управления проектами.
Управление релизами (Release and deployment management).
Планирование и мониторинг жизненного цикла релизов от проектирования до тестирования и
эксплуатации при сохранении работоспособности всех систем / инфраструктуры во время
изменений. Данный процесс в ITIL отвечает за ввод в эксплуатацию программно-аппаратного
обеспечения, которое бы полностью удовлетворяло общей ИТ-архитектуре компании. Сюда
относятся и крупные релизы с большим объемом новой функциональности (возможно, даже
избыточной), и небольшие изменения (содержащие определенные улучшения / исправления), и
срочные доработки для устранения найденных проблем.
Важными элементами управления релизами является контроль версионности, лицензий,
проведение тестирования, управление ожиданиями заказчика и другие аспекты.
Управление уровнем сервиса (Service level management).
Написание и заключение соглашений об уровне услуг SLA для формирования единого
представления о выполнении услуг и его закрепления в виде договорных обязательств. Одним из
признаков успешного управления уровнем сервиса является возможность определения метрик
качества обеспечения сервиса и их сравнения с контрольными / плановыми значениями либо
практиками других подразделений / компаний / отраслей в процессе бенчмаркинга.
Управление финансами (Financial management).
Обеспечение проведения всех необходимых финансовых операций и получения средств для
поддержки ИТ-активов (в частности, задействованных в предоставлении сервисов).
Управление мощностями (Capacity management).
Поддержка оптимальных по ресурсным и стоимостным характеристикам структуры и объема
ресурсов, необходимых для предоставления услуг. При этом в управлении мощностями важно
рассчитывать и общие статеги- ческие потребности, в том числе количество персонала (их
распределение на проекты и потребности в обучении), мощности систем, мощности компонентов
инфраструктуры. В данном процессе очень важно найти компромиссное решение в условиях
риска задействовать недостаточный либо же избыточный объем ресурсов.
Среди активностей этого процесса: сайзинг приложений, управление спросом, управление
рабочей нагрузкой, ресурсами, эффективностью.
Управление непрерывностью (Continuity management).
Обеспечение возможности восстановления нормального режима работы сервисов и проведения
бизнес-операций в случае реализации рисков/ наступления чрезвычайной ситуации. К процессу
также относится снижение вероятности реализации подобных рисков нарушения непрерывности
бизнес-операций.
Для этого в рамках процесса организуются планирование и приоритезация активностей для
проведения анализа бизнес-влияния (business impact analysis), оценка рисков и разработка
альтернативных путей восстановления, включение их в план обеспечения непрерывности,
корректируемый на регулярной основе.
Управление доступностью (Availability management).
Обеспечение возможности представления услуг за счет контроля и управления всех ресурсов, их
поддерживающих. Доступность сервисов часто включается в SLA-соглашения как один из
основных критериев оценки уровня предоставления услуг (и обоснования стоимости сервиса).
В рамках процесса проводятся анализ требований к доступности, составление плана, мониторинг
его исполнения и принятие корректирующих мер. В частности, оценивается стабильность ИТ-
компонентов, поддерживаемость, безопасность, гибкость (зависимость от сбоев аппаратных
платформ).
Решения ITSM обеспечивают автоматизацию, мобильность, повышенную прозрачность и
аналитику в разнообразных процессах управления ИТ-услугами, помогая интегрировать широкий
круг технологий. 
ПРИМЕР.
Служба ИТ-поддержки. Решения IBM IT Service Management (ITSM). 
Решения IBM IT Service Management (ITSM) обеспечивают единую унифицированную платформу
для управления различными процессами управления услугами. Организации могут выйти за
рамки традиционных выполняемых вручную процессов, которые не обеспечивают надлежащую
поддержку планирования в ИТ-среде и операционных направлениях деятельности. 
Решения IBM IT Service Management (ITSM) обеспечивают автоматизацию процессов ITSM на
основе интегрированной технологии, разработанной с учетом отраслевого передового опыта,
включая ITIL, COBIT и ISO/IEC20000.
ПРИМЕР. Решения корпорации Hewlett-Packard (HP) для управления ИТ-услугами. 
Корпорация Hewlett-Packard (HP) – одна из компаний, полностью взявшая на вооружение
рекомендации ITIL. Ее применение позволило HP не только войти в число ведущих поставщиков
услуг консалтинга и внедрения, но и стать одним из крупнейших провайдеров услуг по обучению
основам ITIL и сертификации этих знаний. Компания HP разработала ориентированные на
заказчика стандарты рентабельности ITSM и системный подход к ITSM, которые помогают
заказчику определить, насколько были полезны предоставленные услуги.
Для практического применения ITIL компания HP разработала собственный вариант методологии,
получивший название «Типовой модели HP ITSM» (IT Service Management Reference Model – ITSM
Reference Model). Ее первый вариант был опубликован в сентябре 1997 году. Подчеркнем, что HP
ITSM построена в точном соответствии с ITIL и не противоречит ее положениям. 
Современный ИТ-руководитель должен превратить свою организацию из традиционного
поставщика технологий в поставщика услуг. Для решения этой задачи нужен систематический
комплексный подход к управлению ИТ-услугами (ITSM), который позволит выполнять
поставленные задачи. Такой интегрированный подход позволяет организациям обеспечивать
высокое качество предоставляемых услуг и достигать поставленных целей.
СПИСОК РЕКОМЕНДУЕМОЙ ЛИТЕРАТУРЫ.
[1] Ван Бон Я., Кеммерлинг Г., Пондман Д.  ИТ сервис-менеджмент, введение. –  Русский перевод
«IT Expert». Рус. Редакция – Потоцкий М.Ю. (IT Expert, Главный редактор). –  М., 2003 – 215 c.
[2] Долженко А.И. Управление информационными системами. Курс лекций. Ростов-на-Дону, 2007. 
[3] Зараменских Е.П. Управление жизненным циклом информационных систем. Монография.
Новосибирск: Издательство ЦРНС, 2014. – 270 с. 
[4] Орлова М.М.  Стандартизация управления ИТ-услугами: исторический аспект. НТИ Серия 1.
Организация и методика информационной работы.  Ежемесячный научно-технический сборник.
М.: 2013, № 2. С. 20 – 23.  [5] Экономическая информатика: Введение в экономический анализ
информационных систем: Учебник. – М.:ИНФРА-М, 2005. – 958 с.