«Управление в ИТ»: что такое ITSM и платформа ServiceNow. Роль информационных технологий в становлении бизнес-процессов

Как выбирать персонал

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

На первом уровне нужны специалисты с хорошими техническими знаниями, умеющие оперативно искать проблемы в существующей ИТ-инфраструктуре или быстро пишущие «заплатки» для бизнес-приложений. Руководителю достаточно иметь техническое образование и понимать, что делают его сотрудники. На этапе отбора персонала следует обращать внимание на наличие сертификатов, подтверждающих технические навыки сотрудников. Имеющиеся программы сертификации практически по всем областям современных ИТ-технологий существенно облегчают процедуру подбора специалистов.
На втором уровне руководителю необходимо понимать бизнес-процессы компании, чтобы искать пути их улучшения. Сотрудники ИТ-отдела должны уметь общаться с представителями бизнеса и транслировать их пожелания в ИТ-проекты. Далеко не все сотрудники и руководители, успешно зарекомендовавшие себя на первом уровне, способны безболезненно перейти на второй. Программы развития личностных компетенций и оценка сотрудников по комплексным показателям могут помочь перейти на второй уровень без больших потерь. Тем не менее если компания работает в высококонкурентном бизнесе, то применение стратегии Shape up or ship out («Или развиваем, или увольняем») неизбежно.

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

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

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

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

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

Как измерять эффективность

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

На первом уровне , когда инвестиции в ИТ минимальны и основная финансовая составляющая – это зарплата сотрудников, эффективность ИТ-отдела можно оценивать по соотношению числа ИТ-сотрудников и общего количества работников компании. Приемлемой считается такая цифра: один ИТ-специалист на 50–80 человек, в зависимости от размера компании.
На втором уровне зрелости, когда стоимость ИТ-отдела начинает в большей степени определяться инвестициями в ИТ-технологии, имеет смысл ориентироваться на более комплексный показатель, такой как стоимость ИТ (люди + + технологии) в процентах от оборота компании. В этом случае для типичной не-ИТ-компании можно ориентироваться на цифру 1–3% от оборота. Для высокотехнологичных бизнесов сумма бывает больше.

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

Пирамида зрелости ИТ-отдела с учетом показателей эффективности его работы представлена на рис. 2.

Особенности больших компаний

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

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

• Централизация.
• Виртуализация.

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

Виртуализация – создание команды, географически распределенной, но работающей в единстве. Для взаимодействия сотрудников внутри такой команды применяются современные средства коммуникации и совместной деятельности.
Финансовую выгоду в данном случае дает использование сотрудников в экономически более «выгодных» регионах, где ниже зарплаты и дешевле аренда офисов. При реализации такой стратегии следует уделять особое внимание построению эффективной системы взаимодействия разных частей команды.

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

В определенный момент развития компании руководство ИТ-подразделения может столкнуться с ситуацией, когда решение инцидентов занимает слишком много времени, пользователи оказываются недовольны предоставляемыми услугами, а внутренняя организация работы представляет собой полный хаос. Одним из вариантов решения этих проблем является внедрение ITSM (Information Technology Service Management). В рамках этого поста, которым мы решили открыть свой блог на Хабре, мы поговорим о том, что такое ITSM, и рассмотрим некоторые возможности платформы ServiceNow.

Что такое ITSM?

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

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

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

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

Реализация ITSM - ServiceNow

Сегодня, согласно отчету Gartner, одним из самых популярных ITSM-сервисов на рынке является платформа ServiceNow. «ИТ Гильдия» - официальный партнер компании ServiceNow Ltd., мирового лидера среди поставщиков ПО для управления службой поддержки, достаточно давно работает с платформой ServiceNow, обеспечивая интеграцию, администрирование и техническое сопровождение. Поэтому мы на собственном опыте убедились, что ServiceNow - это гибкая платформа, предоставляющая большие возможности конфигурации под процессы клиента.

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

Это позволяет применить модель ITSM для финансовой службы, HR, службы кадров, маркетинга, а также с помощью единой платформы управлять аналитикой, разработкой, ресурсами, проектами и прочими направлениями бизнеса. А также для типовых ITSM-практик, например, обработки запросов пользователей. Далее, мы рассмотрим несколько решений, которые позволяет применить SaaS-платформа ServiceNow.

Управление ИТ и управление рисками (GRC)

GRC (Governance, Risc, Compliance) - это совокупность процессов и продуктов, участвующих в определении и достижении бизнес-целей и одновременно снижающих риски. GRC в ServiceNow реализована тремя приложениями, полностью интегрированными в основную платформу.

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

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

Второе приложение - это Policy and Compliance Management, и оно обеспечивает централизованный процесс создания и управления политиками, стандартами и процедурами внутреннего контроля. Например, модуль Compliance содержит обзорную информацию о соответствиях, а также списки официальных документов и ссылок компании.

В официальных документах определяются политики, риски, элементы управления, аудиты и другие процессы. Каждый документ прикрепляется к определенной записи, а соответствующие списки в записи содержат индивидуальные условия этого документа.

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

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

Управление разработкой ПО (Agile Development)

Платформа ServiceNow также включает в себя приложения для гибкой разработки. Решение ServiceNow Agile Development (SDLC) позволяет управлять методами гибкой разработки Scrum при работе над программным обеспечением и его сопровождением на протяжении всего жизненного цикла. Приложение Agile Development представляет собой последовательный процесс для среды разработки программного обеспечения.

Платформа дает возможность проводить ежедневные совещания (Daily Scrum) с членами команды с целью обсуждения текущих проектов, запланированных работ и затруднений. Здесь также имеется возможность вести бэклог продукта, представляющий собой список пользовательских историй, упорядоченных по степени важности. Product Backlog можно регулярно просматривать и дополнять по мере появления новых требований и пересмотра приоритетов.

В дополнение к бэклогу продукта решение представляет возможность работать с бэклогом релизов, содержащим список историй, выполнение которых необходимо для выпуска текущей версии разрабатываемого приложения. Как правило, процесс принятия решений основан на шкале времени для релизов, степени важности историй в бэклоге продукта и их сложности.

Управление ИТ-инфраструктурой (IT Operations Management)

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

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

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

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

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

Процесс управления инцидентами

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

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

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

Каким образом это сделать? В одном случае - максимально быстро «починить», в другом - в кротчайшие сроки восстановить наиболее важные функции, в третьем - применить обходное решение, и т.д.

Обходное решение (workaround) - уменьшение или устранение влияния инцидента или проблемы, для которых в текущий момент недоступно полное разрешение.

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

Управления инцидентами (Incident Management) - процесс, отвечающий за управление жизненным циклом всех инцидентов. Управление инцидентами обеспечивает минимизацию влияния на бизнес и восстановление нормального функционирования услуги наиболее быстрым способом.

В рамках достижения цели задачами процесса управления инцидентами являются:

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

Деятельность в рамках процесса управления инцидентами

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

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

• трудно произвести точную регистрацию информации об инциденте, если это не сделано сразу;
• мониторинг хода работ по решению инцидента возможен, только если инцидент зарегистрирован;
• зарегистрированные инциденты помогают при диагностике новых инцидентов;
• Управление проблемами может использовать зарегистрированные инциденты при работе над поиском корневых причин;
• легче определить степень воздействия, если все сообщения (звонки) зарегистрированы;
• без регистрации инцидентов невозможно контролировать исполнение договоренностей (SLA);
• немедленная регистрация инцидентов предотвращает ситуации, когда или несколько человек работают над одним и тем же инцидентом, или никто ничего не делает для разрешения инцидента.

Вся значимая информация об инциденте должна быть зафиксирована и доступна группам поддержки.

Пример информации по инциденту:

При первоначальной регистрации инцидента должна быть проведена его категоризация.

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

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

Каждом инциденту присваивается определенный приоритет.

Приоритет основывается на влиянии и срочности и используется для определения требуемого времени обработки.

Срочность (urgency) - мера того, насколько быстро с момента своего появления инцидент, приобретет существенное влияние на бизнес.

Степень влияния (impact) - мера воздействия инцидента на бизнес-процесс.

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

Приоритет устанавливается с учетом следующих факторов:

• Срочность
• Влияние на бизнес
• Риск для жизни или здоровья (risk to life or limb)
• Число затронутых услуг
• Финансовые потери
• Влияние на репутацию бизнеса
• Влияние на соответствие законам и другим нормами др.

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

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

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

В большинстве случаев ответственной за мониторинг хода решения является Служба Service Desk, как «владелец» всех инцидентов. Эта служба должна также информировать пользователя о состоянии инцидента. Обратная связь с пользователем может быть уместной после изменения статуса, например, направлении инцидента на следующую линию поддержки, изменении расчетного времени решения, эскалации и т. д. Во время мониторинга возможна функциональная эскалация к другим группам поддержки или иерархическая эскалация для принятия руководящих решений.

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

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

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

Политики и базовые принципы процесса управления инцидентами

Политики процесса управления инцидентами должны выполняться для обеспечения результативности и эффективности процесса, и могут включать следующие аспекты:

• Хорошая координация между пользователями и специалистами по решению инцидентов
• Решение инцидентов должно происходить в сроки, согласованные с бизнесом
• Удовлетворенность пользователей должна обеспечиваться на всех этапах решения инцидентов
• Деятельность по управлению инцидентами должна быть согласована с уровнем услуг и задачами поддержки на основе реальных потребностей бизнеса
• Все инциденты управляются, а их данные сохраняются в единой системе управления
• Все инциденты должны иметь стандартную схему классификации, которая соответствует бизнес процессам предприятия
• Записи инцидентов должны регулярно проверяться на предмет правильного ввода и их корректной классификации
• Все записи инцидентов по мере возможности должны иметь общие формат и набор информационных полей
• Должен быть общий и согласованный с бизнесом набор критериев для определения приоритетов и эскалации инцидентов

Ниже описаны базовые принципы, которые должны быть приняты во внимание при внедрении управления инцидентами.

Временные рамки (Timescales) - для всех этапов обработки инцидентов должны быть согласованы временные рамки (они будут различаться в зависимости от уровня приоритета инцидента). Все группы поддержки должны быть в полной мере осведомлены об этих временных рамках.

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

Модель инцидента - это предопределенный способ обработки определенного типа инцидентов.

Модель инцидентов может включать следующие аспекты:

• Предопределенная последовательность действий по обработке определенного типа инцидентов
• Предопределенная ответственность
• Меры предосторожности до решения инцидента
• Временные рамки и процедуры эскалации
• Доказательства деятельности (записи, логи)

В рамках процесса управления инцидента выделяются значительные инциденты.

Значительный инцидент вызывает существенные потери для бизнеса и должны иметь отдельные процедуры обработки.

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

На положение инцидента в процессе обработки указывает статус. Примерами статусов могут быть:

• новый;
• принят;
• запланирован;
• назначен;
• активный;
• отложен;
• разрешен;
• закрыт.

Показатели процесса управления инцидентами

Для управления и оценки эффективности процесса управления инцидентами, а также для обеспечения обратной связи с другими процессами управления, ITIL предлагает использовать следующие основные показатели (CSF и KPI):

• CSF Быстрое решение инцидентов, минимизации их влияния на бизнес
• KPI Среднее время, затраченное на решение инцидента
• KPI Распределение инцидентов по статусам
• KPI Процент инцидентов, решенных первой линией поддержки
• KPI Процент инцидентов, решенных дистанционно
• KPI Количество решенных инцидентов, не повлиявших на бизнес
• CSF Поддержка качества ИТ-услуг
• KPI Общее количество инцидентов (контрольный показатель)
• KPI Размер очереди нерешенных инцидентов по каждой услуге
• KPI Количество и процент значительных (major) инцидентов по каждой услуге
• CSF Поддержка удовлетворенности пользователей
• KPI Средний балл опроса по пользователям /заказчикам
• KPI Процент удовлетворенности ответивших по сравнению с общим числом участвующих в опросе
• CSF Улучшение прозрачности и коммуникаций при решении инцидентов между бизнесом и персоналом поддержки ИТ
• KPI Среднее количество обращений в службу поддержки или других контактов с пользователями по поводу инцидентов, по которым уже было извещение
• KPI Количество претензий и проблем по поводу содержания и качества коммуникаций при решении инцидентов
• CSF Совмещение приоритетов деятельности по управлению инцидентами с приоритетами бизнеса
• KPI Процент инцидентов, решенных без нарушения целей SLA
• KPI Средняя стоимость одного инцидента
• CSF Обеспечение использования стандартных методов и процедур при решении инцидентов
• KPI Количество и процент неправильно назначенных инцидентов
• KPI Количество и процент неправильно классифицированных инцидентов
• KPI Количество и процент инцидентов, обработанных сотрудниками Service Desk
• KPI Количество и процент инцидентов, связанных с изменениями и релизами

Риски и сложности

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

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

Ценность для бизнеса

Внедрив процесс управления инцидентами в соответствии с рекомендациями ITIL и решив все сложности, которые могут возникнуть при внедрении, может быть получена следующая ценность для бизнеса в целом:

• Возможность снизить незапланированные работы и затраты для бизнеса и ИТ, вызванные инцидентами
• Возможность обнаруживать и устранять инциденты, сокращая время простоя и повышая доступность бизнес услуг
• Возможность выделять ресурсы ИТ в соответствии с их приоритетом для бизнеса
• Возможность инициировать улучшение услуг на основании знания природы инцидентов
• Возможность идентифицировать потребности в дополнительном обучении персонала

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

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

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

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

За обеспечение контроля над изменениями в ITIL отвечает ряд процессов преобразования услуг (Service Transition): Управление изменениями, Управление сервисными активами и конфигурациями и управления релизами и развертыванием.

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

В рамках достижения цели задачами процесса управления изменениями являются:

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

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

Деятельность в рамках процесса управления изменениями

На рисунке приведена общая схема процесса управления изменениями. Для обеспечения контроля изменений все изменения должны быть зарегистрированы. При необходимости внесения изменения, входящего в охват процесса, должен быть подан запрос на изменение (request for change, RFC).

Запрос на изменение - формальное предложение на выполнение изменения. Запрос на изменение включает в себя детали предложенного изменения и может быть записан в бумажном или электронном виде. Термин «запрос на изменение» часто неверно употребляется в значениях «запись об изменении» или «изменение» само по себе.

В рамках процесса управления изменения в ITIL выделяется три типа изменений:

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

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

Нормальное изменение - изменение, не являющееся срочным или стандартным. Нормальные изменения обрабатываются по определённым шагам процесса управления изменениями.

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

Ниже приведен пример информации, которая может включаться в запросы на изменение (RFC):

• идентификационный номер запроса;
• номер проблемы/известной ошибки (если имеется), связанной с запросом;
• описание и определение соответствующих конфигурационных единиц;
• причина изменения, включая обоснование и ожидаемый бизнес-результат;
• текущая и новая версия изменяемой конфигурационной единицы;
• имя, адрес и номер телефона лица, направляющего запрос;
• дата подачи;
• предварительная оценка необходимых ресурсов и времени;
• и т.д.

Запрос на изменение создается инициатором, в качестве которого может выступать отдельный человек или группа людей. Если требуется значительное изменение, может потребоваться предложение об изменении (change proposal).

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

Все полученные запросы на изменения должны быть зарегистрирован и для каждого изменения должна быть создана запись об изменении (change record).

Запись об изменении - запись, содержащая детальную информацию об изменении. Каждая запись об изменении документирует жизненный цикл одного изменения. Запись об изменении создается для каждого полученного запроса на изменение, даже если он впоследствии будет отклонён.

После регистрации запроса на изменение (RFC) Управление изменениями делает первичную проверку, нет ли среди них неясных, нелогичных, непрактичных или ненужных запросов. Такие запросы отклоняются с объяснением причин. Сотруднику, направившему запрос, всегда должна быть предоставлена возможность для защиты своего запроса.

Для того чтобы оценить изменение ITIL предлагает ответить на 7 вопросов (7 ‘R’s):

• Кто инициатор? (RAISED) (Who RAISED the change?)
• Какова причина? (REASON) (What is the REASON for the change?)
• Какой требуется результат? (RETURN) (What is the RETURN required from the change?)
• Какие риски связаны с изменением? (RISKS) (What are the RISKS involved in the change?)
• Какие ресурсы требуются для проведения изменения? (RESOURCES) (What RESOURCES are required to deliver the change?)
• Кто отвечает за построение, тестирование и внедрение изменения? (RESPONSIBLE) (Who is RESPONSIBLE for the build, test and implementation of the change?)
• Какие взаимоотношения между этим и другими изменениями? (RELATIONSHIP) (What is the RELATIONSHIP between this change and other changes?)

Если запрос на изменения (RFC) принимается в работу, в запись об изменении включается информация, необходимая для дальнейшей обработки изменения.

Позднее к записи может добавляться следующая информация:

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

После приема запроса на изменение (RFC) определяются его приоритет и категория. Приоритет показывает, насколько важным является данный запрос по сравнению с другими. Это, в свою очередь, определяется его срочностью и степенью воздействия.

Пример системы кодирования приоритетов:

• Низкий приоритет — изменение желательно, но его внедрение может быть отложено до более удобного времени (например, до следующего релиза или планового обслуживания).
• Обычный приоритет — нет особой срочности и высокой степени воздействия, но изменение не следует откладывать.
• Высокий приоритет — изменение касается серьезной ошибки, затрагивающей ряд пользователей, или новой нетипичной ошибки, затрагивающей большую группу пользователей, или связано с другими срочными вопросами.
• Наивысший приоритет — запрос на изменение (RFC) касается проблемы, серьезно влияющей на важнейший для заказчиков сервис. Изменения с таким приоритетом классифицируются как «экстренные».

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

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

Эти коды могут быть представлены в цифрах, например: низкая степень=1/ высшая степень = 3

Большинство изменений относятся к двум первым категориям. На основании оценки влияния изменения должен быть определён уровень авторизации изменения (полномочные лица, change authority), например, как это показано на рисунке.

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

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

В рамках процесса управления изменениями осуществляется ведение графика изменений.

График изменений - документ с перечнем всех утвержденных изменений и плановых дат их реализации, а также с примерными сроками реализации более поздних изменений.

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

Повестка дня совещания совета по изменениям должна включать ряд постоянных пунктов, в том числе:

• Неуспешные или неавторизованные изменения
• Запросы на изменения (RFC), предложенные на рассмотрение членам совета по изменениям в порядке приоритетов
• Запросы на изменения (RFC), рассмотренные советом по изменениям
• Планирование изменения и обновление графика изменений
• Оценки проведенных изменений
• Процесс управления изменениями, дополнения и изменения процесса
• Достижения процесса и выгоды для бизнеса, полученные с помощью процесса управления изменениями
• Незавершенные изменения и изменения в процессе обработки
• Планирование запросов на изменение к рассмотрению на следующем совете по изменениям
• Проверка неавторизованных изменений, обнаруженных процессом управления сервисными активами и конфигурациями

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

Необходимо давать оценку произведенным изменениям, за возможным исключением стандартных изменений. При необходимости совет по изменениям (CAB) принимает решение о проведении последующих дополнительных мероприятий. Должны быть рассмотрены следующие вопросы:

• Изменение достигло поставленных целей?
• Пользователи и заказчики удовлетворены?
• Не возникло побочных эффектов?
• Объем ресурсов, использованных для внедрения изменения, соответствовал запланированному?
• Изменение было внедрено своевременно и без превышения затрат?
• План внедрения функционировал корректно?
• План восстановления функционировал корректно, если это было необходимо?
• И т.д.

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

Оценка результатов внедрения (PIR) - обзор, выполняемый после внедрения изменения или проекта. Оценка результатов внедрения определяет успешность изменения или проекта и выявляет возможности для улучшения.

В зависимости от природы изменения оценку можно проводить или через несколько дней, или через несколько месяцев. Например, оценка изменения в использующемся ежедневно персональном компьютере может быть совершена через несколько дней, а изменение в системе, использующейся раз в неделю, может быть сделана только через три месяца.

Проведение экстренных изменений

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

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

Если для этого нет времени или если запрос поступил в нерабочее время, должен существовать альтернативный способ получения авторизации изменения. Это не обязательно должна быть встреча «лицом к лицу», вместо нее можно провести телефонную конференцию.

Политики и базовые принципы процесса управления изменениями

Политики процесса управления изменениями должны выполняться для обеспечения результативности и эффективности процесса, и могут включать следующие аспекты:

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

Показатели процесса управления изменениями

Для управления и оценки эффективности процесса управления изменениями, а также для обеспечения обратной связи с другими процессами управления, ITIL предлагает использовать следующие основные показатели:

• Процент изменений, удовлетворивших требованиям заказчика
• Польза от изменения, выраженная как «ценность сделанных улучшений» + «предотвращенное негативное воздействие» по сравнению с затратами на проведение изменения
• Уменьшение количества нарушений услуг, дефектов и переделок, вызванных неточными спецификациями или недостаточной оценкой влияния
• Уменьшение количества неавторизованных изменений
• Уменьшение очереди запросов на изменения, процента незапланированных изменений и срочных исправлений
• Уменьшение количества изменений, потребовавших восстановления
• Уменьшение количества неуспешных изменений
• Среднее время исполнения по срочности/приоритету/типу
• Количество инцидентов, связанных с изменением
• Точность оценки изменений

Ценность для бизнеса

Внедрив процесс управления изменениями в соответствии с рекомендациями ITIL и решив все сложности, которые могут возникнуть при внедрении, может быть полученна следующая ценность для бизнеса в целом:

• Выставление приоритетов запросам на изменение от бизнеса и заказчиков и реакция на них
• Внедрение изменений, соответствующих согласованным требованиям к услугам оптимально по затратам
• Уменьшение количества неуспешных изменений, приводящих к прерыванию услуги, дефектам и переделкам
• Проведение изменений в соответствии с временными рамками, определенными бизнесом
• Отслеживание изменений в рамках жизненного цикла услуги и активов своих заказчиков
• Лучшая оценка качества, времени и стоимости изменений
• Оценка рисков, связанных с изменениями услуг (вводом или выводом из эксплуатации)
• Увеличение производительности персонала за счет минимизации количества незапланированных или «срочных» изменений, и, как следствие, увеличение доступности услуг
• Сокращение среднего времени восстановления за счет более быстрого и успешного внедрения корректирующих изменений
• Поддержка связи с процессом изменений бизнеса для выявления возможностей совершенствования бизнеса

Хотели бы Вы, чтобы предоставляемые вам услуги была качественными? Думаю, да. Одной из основных задач ITSM, и ITIL в том числе, является предоставление качественных ИТ-услуг.

Управление ИТ- услугами (IT service management, ITSM) - внедрение и управление качественными ИТ-услугами, которые соответствуют потребностям бизнеса.

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

Качество - способность продукта, услуги, или процесса предоставлять ожидаемую потребителем ценность. Например, качество компонента может считаться высоким, если его работа оправдывает ожидания и обеспечивает требуемую надежность.

Выше приведено определение качества в соответствии с ITIL. Т.е. если мы хотим предоставлять качественные услуги, необходимо чтобы они соответствовали ожиданиям заказчика.

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

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

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

Соглашении об уровне услуги (service level agreement, SLA) - cоглашение между поставщиком ИТ-услуг и заказчиком. Соглашение об уровне услуг описывает ИТ-услугу, документирует целевые показатели уровня услуги, указывает зоны ответственности сторон - поставщика ИТ- услуг и заказчика. Одно соглашение об уровне услуг может распространяться на множество ИТ-услуг или множество заказчиков.

Требование к уровню услуг (service level requirement, SLR) - требование заказчика к ИТ-услуге. Требования к уровню услуг основаны на бизнес-целях и используются для переговоров и согласования целевых показателей уровня услуги.

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

Целевой показатель уровня услуги (service level target) - обязательства, зафиксированные в соглашении об уровне услуг. Целевые показатели уровня услуги основываются на требованиях к уровню услуг и нужны для обеспечения того, чтобы ИТ-услуга соответствовала бизнес-целям. Целевые показатели уровня услуги должны соответствовать критерию SMART, и обычно основаны на ключевых показателях эффективности.

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

Управление уровнем услуг — это процесс, который связывает поставщика ИТ-услуг и заказчика. Этот процесс имеет следующие задачи:

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

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

В охват процесса управления уровнем услуг должно быть включено:

• Организация отношений с бизнесом
• Обсуждение и согласование текущих требований и целей, документирование и сопровождение SLA для предоставляемых услуг
• Обсуждение и согласование требований и целей, документирование и сопровождение SLR для планируемых новых и изменяемых услуг.
• Формирование и сопровождение соглашений операционного уровня (OLA) для поддержки целей SLA.
• Оценка и согласование с целями SLA всех внешних договоров (UC) - совместно с управлением поставщиками.
• Предупреждение сбоев, снижение рисков и внедрение улучшений услуг совместно тс другими процессами.
• Предоставление отчетности и оценку в отношении всех услуг и анализ всех отклонений от целей SLA.
• Инициация и координация плана совершенствования услуг (SIP).

Соглашение операционного уровня (operational level agreement, OLA) - соглашение между поставщиком ИТ-услуг и другой частью той же организации.

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

План совершенствования услуг (service improvement plan, SIP) - формальный план для внедрения улучшений в процессе или ИТ-услуге.

Деятельность в рамках процесса управления уровнем услуг

На рисунке приведена общая схема процесса управления уровнем услуг.

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

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

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

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

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

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

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

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

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

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

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

• соглашения об уровне услуги, основанные на одной услуге;
• соглашения об уровне услуги, базирующиеся на заказчиках;
• многоуровневые соглашения об уровне услуг.

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

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

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

Комбинация любых вариантов структуры возможна при условии отсутствия дублирований.

Некоторые организации используют многоуровневую структуру соглашений об уровне услуг. Она может включать в себя, например, три уровня:

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

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

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

Необходимо убедиться, что администрирование многоуровневых SLA контролируется, так как любое введенное изменение будет иметь влияние на других уровнях. Это касается любых изменений, сделанных в корпоративном SLA - они должны быть сообщены другим уровням. Администрирование многоуровневых SLA сложное, но оно проще, чем администрирование большого количества SLA, не объединенных в такую иерархию.

Многие организации считают необходимым использовать стандарты и/или шаблоны соглашений, которые используются как основа при подготовке конкретных соглашений об уровне услуг. Такие шаблоны могут быть использованы для разработки набросков (проектов) соглашений.

Разработка стандартов и образцов обеспечивает последовательную разработку всех соглашений, что в свою очередь облегчает их последующие использование, управление и эксплуатацию.

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

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

Важно, чтобы задокументированные и согласованные цели были разъяснены, специфичны и недвусмысленны, так как они предоставляют базу для отношений и обеспечения качества предоставляемой услуги.

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

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

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

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

Для начала стоит попробовать управлять ожиданиями заказчиков. Это значит сформировать верные ожидания и цели, а затем систематически проактивно их корректировать, помня, что «удовлетворенность = восприятие - ожидания» (при значении большем или равном нулю заказчик удовлетворен). Соглашение об уровне услуг - это просто документы, и сами по себе не заменяют качество предоставляемой услуги (хотя и могут влиять не поведение и могут способствовать развитию должной культуры услуги, что даст и кратко- , и долгосрочный положительный эффект). Определенная степень терпения должна быть проявлена и быть частью ожиданий.

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

• периодическое анкетирование и опросы заказчиков;
• обратная связь на встречах по оценке услуг;
• обратная связь при проведении оценки проведенных изменений;
• телефонные опросы, проводимые службой Service Desk;
• анкеты удовлетворенности, раздаваемые при выполнении обслуживания и др. контактах;
• общение с группами пользователей (на форумах и т.п.);
• анализ жалоб и благодарностей.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Показатели процесса управления уровнем услуг

• CSF Важно обеспечить управление качеством сервисов в целом, включая охват и уровень предоставления:
• KPI Доля снижения несоответствий целям SLA
• KPI Доля снижения угроз несоответствий
• KPI Доля улучшений в восприятии и удовлетворенности заказчиков достижениями SLA на основании встреч по оценке сервисов и опросов удовлетворенности
• KPI Доля снижения несоответствий, связанных с зависимостью от третьих сторон (UC)
• KPI Доля снижения несоответствий, связанных с зависимостью от внутренних подрядчиков (OLA)
• CSF Предоставление сервисов в соответствии с договоренностями за приемлемые деньги:
• KPI Число и доля повышения числа полностью документированных SLA
• KPI Доля улучшений в SLA, направленных на совершенствование уже предоставляемых сервисов
• KPI Доля снижения стоимости предоставления сервисов
• KPI Доля снижения стоимости мониторинга и отчетности по SLA
• KPI Доля повышения скорости разработки и согласования SLA
• KPI Частота встреч по оценке сервисов
• CSF Управление интерфейсом между бизнесом и пользователями:
• KPI Повышение числа сервисов, покрытых SLA
• KPI Документирование и согласование процесса и процедур SLM
• KPI Снижение времени ответа и исполнения для запросов на SLA
• KPI Повышение доли SLA, пересматриваемых вовремя
• KPI Снижение доли невыполненных SLA, подлежащих пересмотру
• KPI Снижение доли SLA, требующих корректировки
• KPI Повышение охвата OLA и UC при снижении числа соглашений за счет их консолидации и централизации
• KPI Наличие документальных свидетельств улучшений по выявленным отклонениям от SLA
• KPI Снижение числа и тяжести несоответствий целям SLA
• KPI Эффективная оценка и обработка всех отклонений и несоответствий от SLA, OLA, UC

ITIL выделяет субъективные и объективные показатели эффективности управления уровнем услуг. Объективные:

• Число или доля достигнутых целей услуги
• Число и степень (тяжесть) отклонений и нарушений
• Число актуальных SLA (up-to-date)
• Число услуг, по которым своевременное предоставляется отчетность и проводится оценка

Субъективные:

• Улучшения удовлетворенности заказчиков

Риски и сложности

При внедрении управления уровнем услуг необходимо учитывать следующие возможные риски и сложности:

• Недостаток точных входных данных, вовлеченности и заинтересованности со стороны бизнеса и заказчиков
• Потребность в ресурсах и инструментарии для согласования, документирования, мониторинга, отчетности и оценки соглашений и уровней услуг
• Процесс может стать излишне бюрократичным, ориентированным на административные процедуры, а не на фактическое проактивное улучшение услуг
• Доступ и поддержка корректных и актуальных CMS и SKMS
• Неисполнение процедур SLM
• Бизнес ориентированные метрики слишком сложно мерить и улучшать, поэтому они не собираются
• Несоответствующий задачам уровень контакта и согласования
• Высокие ожидания и низкая удовлетворенность заказчиков
• Неэффективные коммуникации с бизнесом

Процесс управления проблемами

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

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

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

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

Управление проблемами включает в себя проактивные (упреждающие) и реактивные виды деятельности. Задачей реактивных составляющих процесса управления проблемами является выяснение корневой причины прошлых инцидентов и подготовка предложения по ее ликвидации. Проактивное управление проблемами помогает предотвратить инциденты путем определения слабых мест в инфраструктуре и подготовки предложений по ее усовершенствованию.

Таким образом, задачами процесса управления проблемами являются:

• Предотвращение возникновения проблем и связанных с ними инцидентов
• Прекращение повторения инцидентов
• Снижение влияния инцидентов, которые не могут быть предотвращены

Деятельность в рамках процесса управления проблемами

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

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

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

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

Возможными признаками проблем могут быть:

• Инциденты, повторяющиеся в:
• Один и тот же временной промежуток
• В одной предметной области (категории)
• В одном и том же CI или группе однотипных CI
• В одних и тех же локации, заказе, подразделении
• Объем однотипных инцидентов превышает некий уровень
• Для решения инцидента применено обходное решение
• Превышение предельного срока обработки инцидента(ов)

Анализ тенденций позволяет обнаружить области, которым требуется особое внимание. Независимо от метода обнаружения проблемы, все значимые данные о проблеме должны быть зафиксированы в записи о проблеме (problem record):

• Информация о пользователе(-ях)
• Информация об услуге(-ах)
• Информация об оборудовании
• Время регистрации
• Приоритет, категория
• Описание связанных инцидентов
• Предпринятые для диагностики и решения действия

Запись о проблеме - запись, содержащая детальное описание проблемы. Каждая запись о проблеме документирует жизненный цикл одной проблемы.

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

Классификация проблемы включает в себя следующее:

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

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

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

После определения причины проблемы и обходного решения, проблеме присваивается статус «Известной ошибки». Во многих случаях обходное решение для проблемы уже имеется изначально, даже если ошибка найдена самими разработчиками. Но в некоторых случаях обходное решение нужно найти, а затем передать его в процесс управления инцидентами.

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

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

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

После окончания этапа выбора существует достаточно информации для подачи запроса на изменение. Далее исправление проблемы (известной ошибки) будет произведено под контролем процесса управления изменениями.

Изменение, предназначенное для решения проблемы, должно быть рассмотрено при оценке результатов внедрения до закрытия проблемы. Если изменение дало ожидаемый результат, проблема может быть закрыта, и в базе данных о проблемах ее статус будет изменен на статус «решена». Управление инцидентами будет проинформировано об этом и инциденты, связанные с этой проблемой, тоже могут быть закрыты.

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

В течение всего процесса информация об обходных решениях и быстрых исправлениях передается в управление инцидентами. Пользователи также могут информироваться об этом.

Политики и показатели процесса управления проблемами

Политики процесса управления проблемами должны выполняться для обеспечения результативности и эффективности процесса, и могут включать следующие аспекты:

• Проблемы должны отслеживаться отдельно от инцидентов
• Все проблемы должны храниться и управляться единой системой управления
• Все проблемы должны иметь стандартную схему классификации, которая соответствует бизнес процессам предприятия

Для управления и оценки эффективности процесса управления уровнем услуг, а также для обеспечения обратной связи с другими процессами управления, ITIL предлагает использовать следующие основные показатели (CSF и KPI):

• CSF Минимизация влияния на бизнес инцидентов, которые не могут быть предотвращены
• KPI Количество известных ошибок добавляется KEDB
• KPI Процент актуальности KEDB (по аудиту базы данных)
• KPI Процент инцидентов, закрытых службой поддержки («первой точкой контакта»)
• KPI Среднее время решения инцидентов, по которым открыта проблема
• CSF Поддержка качества ИТ-услуг путем устранения повторяющихся инцидентов
• KPI Общее количество проблем (как контрольный параметр)
• KPI Размер очереди по проблемам для каждой ИТ-услуги
• KPI Количество повторно случившихся инцидентов для каждой ИТ-услуги
• CSF Обеспечение качества и профессионализма в решении проблем для поддержания уверенности бизнеса в возможностях ИТ
• KPI Количество значительных проблем (открытых, закрытых и очередь)
• KPI Процент успешно выполненных обзоров значительных проблем
• KPI Процент обзоров значительных проблем, завершенных успешно и в срок
• KPI Количество и процент проблем, назначенных неправильно
• KPI Количество и процент проблем с неверной категоризацией
• KPI Очередь накопившихся нерешенных проблем и её тенденция
• KPI Количество и процент проблем, превысивших сроки решения
• KPI Процент проблем, решенных в рамках целей SLA целей
• KPI Средняя стоимость решения одной проблемы

Ценность для бизнеса

Внедрив процесс управления инцидентами в соответствии с рекомендациями ITIL и решив все сложности, которые могут возникнуть при внедрении, может быть полученная следующая ценность для бизнеса в целом:

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

Процесс управления сервисными активами и конфигурациями

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

• сложность актуализации: при внесении каждого изменения схему необходимо перерисовать и печатать заново, в противном случае на нее нельзя полагаться в случае необходимости
• ограниченный охват: компоненты инфраструктуры могут быть очень тесно переплетены между собой и не всегда все элементы могут быть отражены на схеме
• ограниченность информации: как правило, для каждого элемента указывается только самая важная информация, например, доменное имя или IP-адрес
• сложность анализа: при большом охвате схемы и при наличии различных сложных взаимосвязей между компонентами, анализ таких схем затруднителен

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

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

Управления сервисными активами и конфигурациями включает в себя два подпроцесса:

• Управление активами (Asset Management) - деятельность или процесс, отвечающий за отслеживание и предоставление отчётности о ценности и владении активами на всём протяжении их жизненного цикла
• Управление конфигурациями (Configuration Management) - деятельность или процесс, отвечающий за управление информацией о конфигурационных единицах, необходимой для предоставления ИТ-услуг, включая их взаимоотношения.

Задачи процесса управления сервисными активами и конфигурациями:

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

Ядром процесса является система управления конфигурациями (CMS). CMS позволяет обеспечить хранение всей необходимой конфигурационной информации, ее анализ и представление в различных разрезах.

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

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

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

• записи о конфигурационных единицах, включающие соответствующие им атрибуты
• взаимоотношения (связи) между конфигурационными единицами

Атрибуты позволяют учитывать информацию, необходимую для определённого типа конфигурационных единиц. Например, для серверов и ноутбуков может быть интересна такая информация, как производитель, доменное имя, срок гарантии и т.д. При этом для программного обеспечения эта информация скорее всего будет отличаться.

Атрибут - часть информации о конфигурационной единице. Например, наименование, местоположение, номер версии и стоимость. Атрибуты КЕ записываются в базу данных управления конфигурациями (CMDB) и поддерживаются как часть системы управления конфигурациями (CMS).

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

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

Совокупность КЕ и их взаимоотношений фактически представляют собой конфигурационную модель. На рисунке представлен пример конфигурационной модели.
CMS позволяет эффективным образом учитывать необходимую конфигурационную информацию, анализировать и представлять в различном виде, включая графический. CMS предоставляет информацию другим процессам управления услугами:

• для оценки влияния инцидентов и проблем
• для оценки влияния изменений
• для планирования и проектирования новых и изменяемых услуг
• для планирования обновления технологий и ПО
• для планирования пакетов релиза и тиражирования услуг
• для оптимизации использования активов и затрат

Таким образом, в случае если управление сервисными активами и конфигурациями реализовано эффективно, то этот процесс может дать, например, информацию о следующем:

• Финансовая информация и политика компании в отношении продуктов
• Какие ИТ-компоненты используются в настоящее время по каждой модели (версии) и на протяжении какого времени?
• Какие тенденции существуют в разных группах продуктов?
• Какова текущая и остаточная стоимость ИТ-компонентов?
• Какие ИТ-компоненты нужно выводить из операционной среды и какие требуют модернизации?
• Сколько будет стоить замена определенных компонентов?
• Какие имеются лицензии и достаточно ли их?
• Какие контракты на сопровождение следует пересмотреть?
• Какова степень стандартизации инфраструктуры?
• Выявление неисправностей и оценка результатов
• Какие ИТ-компоненты необходимы для поддержки процесса восстановления в случае чрезвычайной ситуации?
• Будет ли работать план восстановления на случай чрезвычайных обстоятельств, если была изменена конфигурация инфраструктуры?
• Какие ИТ-компоненты будут затронуты при развертывании новых сервисов?
• Как оборудование подключено к сети?
• Какие программные модули входят в каждый из комплектов программного обеспечения?
• Какие ИТ-компоненты затрагиваются изменениями?
• Какие запросы на изменение (RFC) конкретных ИТ-компонентов находятся на рассмотрении и какие инциденты и проблемы произошли в прошлом и сейчас продолжают оставаться актуальными?
• Какие ИТ-компоненты вызывают известные ошибки?
• Какие ИТ-компоненты были закуплены у конкретного поставщика в течение определённого периода?
• Предоставление услуг и выставление счетов
• Какие конфигурации ИТ-компонентов являются существенными для определенных услуг?
• Какие ИТ-компоненты используются в том или ином месте и кем?
• Какие стандартные ИТ-компоненты может заказать пользователь и какие из них поддерживаются (каталог продуктов)?

Деятельность в рамках процесса управления сервисными активами и конфигурациями

На рисунке приведена схема типовых деятельностей по управлению конфигурациями.

В материалах ITIL «планирование» означает деятельность по организации самого процесса управления конфигурациями. Управление и планирование как вид деятельности, применяется как на этапе создания, так и на этапе совершенствования процесса. Основным результатом планирования является «План управления конфигурациями».

План управления конфигурациями содержит.

• Описание процесса управления конфигурациями
• Высокоуровневое описание системной архитектуры
• План значительных мероприятий (идентификации, крупных релизов и проч.)

План является «живым» документом и подлежит регулярному пересмотру. За актуализацию плана отвечает менеджер процесса управления конфигурациями.

Деятельность по идентификации конфигураций включает:

• Определение и документирование критериев по выбору конфигурационных единиц и составляющих их компонентов
• Выбор конфигурационных единиц и компонентов на основе документированных критериев
• Присвоение уникальных идентификаторов
• Определение атрибутов для каждой КЕ
• Определение момента, когда КЕ берется под контроль процесса
• Определение владельца, ответственного за каждую КЕ

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

Деятельность по управлению КЕ включает следующие аспекты:

• Поддержание данных CMDB в актуальном состоянии
• Обеспечение целостности данных CMDB (понятны происхождение и история изменений каждой КЕ)
  • Ограничение доступа на изменение данных CMDB
  • Обеспечение антивирусной защиты средств управления CMDB
  • Обеспечение резервного копирования и возможности восстановления данных
• Правила контроля должны быть разработаны на этапе планирования процесса
• Правила передачи контроля от проектов или поставщиков
• Процедуры контроля должны соответствовать типам КЕ

В деятельность по учету статуса конфигураций и отчетности входит:

• Поддержка конфигурационных записей в ходе жизненного цикла услуги и архивация их в соответствии с соглашениями, внешними требованиями, передовым опытом и стандартами (например ISO 9001)
• Управление документированием, получением и консолидацией текущего статуса конфигурации и статусов всех предшествующих конфигураций для обеспечения корректности, своевременности, целостности и безопасности информации
• Обеспечение доступности информации о статусе в течение жизненного цикла услуги
• Документирование изменений CI от приемки до вывода из эксплуатации
• Обеспечение правильного документирования базовых конфигураций

Верификация и аудит:

• Верификация - проверка КЕ на соответствие стандартам или функциональным требованиям:
• При первичной регистрации в CMDB
• При получении оборудования или ПО от поставщика
• При вводе в эксплуатацию
• Аудит - проверка соответствия между актуальным состоянием КЕ (как есть) и описанием КЕ в CMDB (как должно быть)
• Стандартный аудит
• Упрощенный аудит
• Текущий (операционный) аудит

• Спустя небольшой промежуток времени после внедрения новой системы / процесса управления конфигурациями
• Перед и после крупных изменений в ИТ инфраструктуре
• Перед развертыванием нового ПО для проверки готовности продуктивной среды
• После восстановления от крупного сбоя (чрезвычайной ситуации)
• По факту обнаружения большого количества расхождений (например, в рамках операционного аудита)
• Регулярно (с заранее определенной периодичностью)
• Время от времени («внезапные» проверки)

Показатели процесса управления сервисными активами и конфигурациями

Для управления и оценки эффективности процесса управления изменениями, а также для обеспечения обратной связи с другими процессами управления, ITIL предлагает использовать такие основные показатели, как например:

• Процент улучшения поддержки жизненного цикла актива по принципу: не слишком много, не слишком поздно
• Степень соответствия поддержки потребностям бизнеса
• Активы, идентифицированные как причина сбоев в предоставлении услуг
• Увеличение скорости решения инцидентов и восстановления услуг через более быстрое определение сбойных КЕ
• Выявление связей между специфическими типами КЕ, инцидентами и проблемами
• Более эффективное использование сервисных активов
• Более эффективное использование закупленных лицензий, средняя стоимость лицензии на одного пользователя
• Более точные бюджет и оплата за использование активов
• Более эффективные аудиты активов
• Улучшение качества и точности информации об активах
• Меньше ошибок, вызванных работой с устаревшими данными
• Уменьшение количества и объемов аудита
• Уменьшение использования неавторизованного оборудования и ПО, что ведет к уменьшению стоимости и рисков в поддержке услуг
• Уменьшение времени и снижение стоимости при диагностике и решении инцидентов и проблем
• Уменьшение времени идентификации активов, проблемных по производительности
• Уменьшение количества неуспешных изменений, причиной чего явилась неверная оценки влияния, некорректные данные в CMS или плохой контроль версий
• Снижение рисков благодаря раннему обнаружению несанкционированных изменений

Сложности

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

• Убеждение персонала технической поддержки соблюдать политики учета, что часто воспринимается как препятствие в быстрой поддержке услуг.
• Привлечение и обоснование выделения фондов для процесса, так как, обычно, процесс не виден подразделениям заказчика, обладающим полномочиями по выделению фондов. Обычно финансируется как «невидимый» элемент управления изменениями и других более «заметных» процессов
• Подход: «собираем все данные, которые возможно», что ведет к перегрузке процесса, а также к невозможности его поддерживать
• Недостаток приверженности и поддержки руководства, не понимающего ключевую роль процесса

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.

Размещено на http://www.allbest.ru/

Введение

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

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

Объект исследования диссертации: бизнес-процессы в ИT.

Предмет исследования диссертации: организация моделирования бизнес-процессов и управления в ИT предприятии.

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

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

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

Задачи, поставленные для достижения цели:

1) Проведение анализа литературных источников по поставленной проблеме:

· Определение роли концепции управления ИT-услугами в понимании бизнес стратегии;

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

· Проведение обзора и анализа существующих методик, методологий, лучших практик, рекомендаций, которые используются для управления ИT-процессами (ITIL, COBIT, ISO 20000);

2) Проведение исследования основных бизнес-процессов в ИT:

· Описание бизнес-процессов, их назначения, целей, задач и функций.

· Определение окружения и взаимодействия с другими процессами.

· Определение метрик процессов.

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

· Описать процессы, происходящие внутри каждого бизнес процесса.

· Разработать схемы моделирования бизнес процессов в ИT.

4) Построить общую инфраструктуру ИТ-предприятия.

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

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

Магистерская диссертация представлена на ____ стр. текста и состоит из введения, четырех глав, заключения и списка литературы.

В первой главе произведен анализ научно-технической литературы, статей из российских и зарубежных журналов на тему управления процессами в ИT. Определены сущности компонентного и сервисного подхода. Изучены основные стандарты и практики, которые в настоящий момент применяются для управления процессами и службами на предприятиях. Проанализированы методы моделирования бизнес-процессов.

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

В третьей главе проведено моделирование бизнес-процессов, описаны операции, протекающие на всем цикле работ, разработан каталог рисков, безопасности и метрик.

В четвертой главе описана общая инфраструктура всех процессов.

1. Обзор решений моделирования бизнес-процессов управления ИT сервисами

1.1 Роль концепции управления ИT-услугами в понимании бизнес стратегии

Более 60-ти лет назад появились первые электронно-вычислительные системы и комплексы, которые стали главным катализатором для переворота в промышленности, они позволили автоматизировать труд человека, значительно увеличить его производительность и ускорить темпы производства. Первые компьютеры были примитивными, занимали большие площади и выполняли лишь узконаправленные операции. В роли бизнеса в основном выступали военные организации, научно-исследовательские центры и институты, владеющие такими машинами, и только с течением времени к этому списку присоединились мировые корпорации. В процессе развития каждая смена поколений ЭВМ обуславливалась стремительным скачком в развитии технологий и требовала радикальной смены мышления пользователей систем и переобучения специалистов.

В 2000-х годах в результате мощного прогресса информационных технологий, в том числе и благодаря освоению ресурсов интернет пространства, всеобщая доступность ИT-услуг привела к повсеместной интеграции во взаимодействии человека с компьютером. Современные средства вычислительной техники являются не только неотъемлемой частью повседневной жизни людей (доступность технических средств, появление различных торговых площадок в сети интернет, онлайн-сервисов, интернет-магазинов, интернет-банкингов, интернета-вещей, развитие интеллектуальных систем и технологий Big Data), но и главным двигателем бизнеса.

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

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

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

1.2 Сравнительный анализ существующих подходов к управлению IT-услугами

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

Выполнение заданий, связанных с ИТ обеспечением предприятия (внедрение, сопровождение),

Обеспечение стабильного функционирования ИТ комплекса.

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

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

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

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

· повышение качества услуг, предоставляемых конечным пользователям;

· обеспечение непрерывности бизнес-процессов и услуг;

· сокращение затрат на содержание ИТ-инфраструктуры.

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

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

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

1.3 Анализ существующих методик, стандартов и подходов к управлению ИT-процессов

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

В основу «лучших практик» («best practice») и методологий различных подходов к управлению ИТ-услугами, разработанных крупными компаниями-вендорами входят следующие группы: методологии управления ИТ-услугами (ITIL, MOF, HP References model), подходы к руководству ИТ (IT Governance, CobiT), а также, частично, методологии управления проектами (IPMA, PMI, PRINCE2) в части управления проектами в области ИТ.

К стандартам относится первый в мире международный стандарт по управлению услугами ISO 20000, стандарты в области управления информационной безопасностью ISO 27001, стандарты в области разработки программного обеспечения ISO 12207, ISO 15288, ISO15504 и другие.

1.3.1 Библиотека ITIL

ITIL (IT Infrastructure Library) - библиотека, описывающая лучшие из применяемых на практике способов организации работы подразделений или компаний, занимающихся предоставлением услуг в области информационных технологий.

Создание проекта началось в 80-е годы Центральным агентством по вычислительной технике и телекоммуникациям (CCTA - Central Computer and Telecommunications Agency). Целью проекта было создание подхода, который бы помог результативно и эффективно использовать IT-ресурсы в министерствах и других государственных учреждениях по заказу британского правительства. Результатом работ стала Библиотека опыта организации IT (IT Infrastructure Library -- ITIL), которая собрала лучшие подходы, имеющиеся на тот момент в индустрии IT-услуг.

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

Рассмотрим основные принципы, на которых основана модель ITIL:

Процессный подход к построению деятельности IT-департамента;

Услуга как конечный продукт IT-подразделения;

Высокое качество предоставляемых услуг;

Вектор внимания на Потребителя;

Ключевые отношения Поставщик-Потребитель;

Взаимовыгодные отношения с Поставщиками.

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

Основное внимание уделяется 12-ти практическим управленческим методам, которые применяются в различных областях в зависимости от потребностей организации (рис. 1.1).

Рисунок 1.1 - Библиотека ITIL

Библиотека ITIL состоит из подробных сведений, которые отвечают на один из вопросов о том, каким образом возможно предоставление и поддержание ИТ-услуг и сервисов (Service Delivery, Service Support, Application Management). В практике описываются процессы создания, развертывания и поддержания ИТ-инфраструктуры (Infrastructure Management) на качественном уровне, способном соответствовать всем ожиданиям клиента.

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

Применение ITIL организацией позволяет решать следующие задачи:

· Повышать эффективность выполнения протекающих процессов, использующих современные информационные технологии, в том числе:

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

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

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

ь организации сервисно-процессного подхода к организации ИТ-деятельности;

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

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

· Обеспечивать увеличение управляемости протекающими процессами и их развития (в том числе, повышение управляемости и прозрачности), обеспечение принятия своевременных, взвешенных и обоснованных управленческих решений за счет:

ь определения и параметризации объективных показателей оценки качества ИТ-сервисов, качества работы подразделений и сотрудников ИТ, обеспечения критериальной оценки работы ИТ-сервисов, отдельных сотрудников, подразделений и службы ИТ в целом;

ь создания системы автоматизированной отчетности, формируемой по фактическим значениям показателей качества ИТ-сервисов и работы службы ИТ;

ь создания системы непрерывного совершенствования и развития ИТ-сервисов и процессов управления ИТ.

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

1.3.2 MOF

Ведущи е мировые компании-вендоры, занимающиеся производством программного и аппаратного обеспечения на практике разрабатывают на основе ITIL структурированные подходы (frameworks), отображающие точку зрения своей компании на управление ИТ-услугами. Одной из самых интересных «надстроек над ITIL» является Microsoft Operations Framework (MOF).

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

Модель процессов MOF поддерживает успешное оказание ИТ-услуг при помощи следующих важнейших принципов:

Структурированная и распределённая ИТ архитектура;

Быстрый жизненный цикл, итеративное улучшение;

Управление, основанное на оценке;

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

Модель процессов MOF делится на 4 взаимосвязанных квадранта операционной активности: изменение, эксплуатация, поддержка и оптимизация. Каждый из квадрантов применяется на определенном этапе жизненного цикла ИТ инфраструктуры. Задача каждого из квадрантов решается путем исполнения соответствующих функций управления услугами (рис. 1.2).

Рисунок 1.2 - Модель процессов MOF

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

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

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

Вывод: Значительным и достаточно критичным недостатком MOF есть тот факт, что данная «надстройкой над ITIL» является непосредственным подходом Microsoft к управлению ИТ-услугами и использованием продуктов именно в рамках данной конкретной организации. Применение MOF нельзя считать универсальным подходом, возможным для использования в других компаниях или организациях, т.к. он представляет из себя крайне узконаправленный и подточенный под конкретную организацию подход не гарантирующий успех.

1.3.3 Стандарт CobiT

Стандарт Control Objectives for Information and related Technology (CobiT) представляет собой набор универсальных задач ИТ управления. Его ценность заключается в том, что он предлагает модель, обеспечивающую взаимосвязь между бизнес-целями и ИТ-процессами.

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

CobiT содержит верхнеуровневое описание 34-х ИТ-процессов различных аспектов корпоративного ИТ управления. Все процессы сгруппированы в четыре домена (рис. 1.3):

· Планирование и организация (Plan and organize);

· Приобретение и внедрение (Acquire and implement);

· Предоставление и поддержка (Deliver and support):

ь Определение и управление уровнями сервиса,

ь Управление сервисами подрядчиков,

ь Управление производительностью и мощностью,

ь Обеспечение непрерывности сервисов,

ь Обеспечение безопасности систем,

ь Определение и распределение ИТ затрат,

ь Обучение пользователей,

ь Управление службой поддержки и инцидентами,

ь Управление конфигурацией,

ь Управление проблемами,

ь Управление данными,

ь Управление физическим оборудованием,

ь Управление эксплуатацией,

· Мониторинг и оценка (Monitor and evaluate).

Рисунок 1.3 - Стандарт CobiT

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

Достоинствами CobiT является четкая структура механизмов контроля процессов и возможности проведения аудита ИТ-процессов на соответствие требованиям.

Основываясь на стандарте CobiT для проведения любых модернизаций и усовершенствований в организации описан ряд подготовительных мероприятий для того, чтобы:

· определить четкие требования к ИТ-службе;

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

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

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

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

Единственное, что не описано в CobiT - это вопросы внедрения процессов, механизмы осуществления деятельности (включая управление) процессов, меры по совершенствованию ИТ процессов и услуг.

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

1.3.4 Стандарт ISO 20000

Первый в мире стандарт в области управления услугами официально разрабо танный Британским институтом Стандартизации (British Standard Institute) - BS 15000. Стандарт ISO/IEC 20000 «определяет требования к поставщику услуг по предоставлению потребителю управляемых услуг приемлемого качества» и «должен способствовать принятию в повседневной практике процессного комплексного подхода к эффективному предоставлению управляемых услуг».

ISO/IEC 20000 состоит из двух частей:

· Information Technology - Specification for Service management (ISO/IEC 20000-1: 2005). Набор формальных требований для организации предоставления ИТ-услуг с требуемым качеством;

· Information Technology - Code of Practice for Service management (ISO/IEC 20000-2:2005). Практическое руководство по управлению ИТ-услугами. В нем в форме рекомендаций подробно раскрываются подходы к достижению формальных требований, изложенных в первой части стандарта.

Рисунок 1.4 - Стандарт ISO/IEC 20000

Стандарт ISO/IEC 20000 вобрал в себя принципы процессного подхода и содержит ряд требований к процессам управления ИТ-услугами. В стандарте описаны процессы управления услугами (рис. 1.4), но не отображены взаимосвязи между процессами.

Согласно стандарту, необходимо обеспечить «систему управления, включающую политики и организацию управления, позволяющую реализовывать внедрение всех услуг ИТ и эффективное управление ими». Планирование и реализация управления услугами реализуется через цикл Деминга «Plan-Do-Check-Act» (PDCA). При этом описание цикла и действий, которые должны быть осуществлены на каждом этапе, практически полностью совпадают с описанием цикла PDCA, приведенного в стандарте ISO/IEC 9000 с учетом специфики ИТ-услуг:

Ш планирование (plan) - установка целей управления услугами и определения процессов управления услугами, необходимых для получения результатов, соответствующих требованиям потребителей и политикам поставщика услуг;

Ш реализация (do) - внедрение процессов управления услугами;

Ш проверка (check) - контроль и измерение процессов управления услугами и самих услуг. Предметом контроля и измерения должно быть соответствие этих процессов и услуг политикам поставщика услуг, целям управления услугами и требованиям потребителей услуг;

Ш действие (act) - выполнение действий по постоянному улучшению показателей процессов.

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

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

Project Management Body of Knowledge (PMBoK) - свод знаний по управлению проектами и является американским национальным стандартом. В стандарте описывается непосредственно процесс управления проектами в терминах интеграции между процессами и взаимодействий между ними, а также цели, которым они служат.

По PMBoK управление проектами - это приложение знаний, навыков, инструментов и методов к работам по управлению процесса для удовлетворения требований, предъявляемых к проекту. Управление проектами выполняется с применением интеграции логически сгруппированных процессов управления проектами в количестве 42, распределенных в 5 групп. Эти 5 групп процессов следующие:

· инициация;

· планирование;

· исполнение;

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

· завершение.

Вывод: Знания, которые накоплены в PMBoK по управлению проектами являются одними из наиболее часто используемых и при их правильном применении внедрение проектов в рамках ИТ-инфраструктуры будут приносить прибыль и обеспечивать эффективные показатели качества.

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

PRINCE2 является методом для упра вления проектами, разработанным для британского правительства и является обязательным для применения во всех государственных структурах Великобритании. Благодаря открытости, доступности и эффективности этого метода, им активно пользуются уже более чем в 150 странах мира и его популярность растет с каждым днем. Уже более 23 000 организаций по всему миру уже используют этот инновационный и надежный подход в своей практике и многие считают его лучшим методом управления проектами. Во многом это связано с тем, что PRINCE2 является действительно универсальным методом: он может быть применен к проектам в любой сфере деятельности и вне зависимо от различных условностей.

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

PRINCE2 -- основан на четком процессе, разбитом на 8 стадий и 45 подпроцессов. У каждой стадии есть свой набор целей, активностей, а также входных и выходных артефактов. Есть критерии, по которым можно судить о качестве артефактов. Они позволяют контролировать отклонения от качества в течение жизненного цикла проекта.

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

В сравнении с другими лучшими практиками и методами управления проектами, а именно PMBoK, PRINCE2 обеспечивает следующие преимущества:

Универсальность применения по отношению к любому типу проекта;

Единство терминологии и подходов;

Интегрируемость с другими практиками и со специфическими отраслевыми моделями и методологиями;

Фокус управленческих усилий на продукте проекта, в соответствии с согласованными стандартами качества;

Управляемость по отклонениям, с обеспечением эффективного использования времени руководителей;

Непрерывность внимания обеспечения жизнеспособности и целесообразности проекта;

Распределение ролей и зон ответственности участников.

Вывод: Применение PRINCE2 на практике характеризуется его функциональностью по отношению к различному уровню проектам. Построение внедрения услуг на подходах и знаниях PRINCE2 гарантирует понятность протекающего процесса, прозрачность и эффективность.

1.3.7 Capability Maturity Model Integration (CMMI)

Комплексная модель производительности и зрелости (CMMI) представляет из себя набор моделей (методологий) совершенствования процессов в организациях с разным размеров и видов деятельности. В CMMI существует набор практик, реализация которых позволяет достигнуть определенного уровня качества некоторых областей деятельности.

Потребность в появлении данной методологии возникла в кулуарах Министерства обороны США с целью решения такого вопроса, как повышение качества разрабатываемого по заказу ПО. Разработкой модели, в соответствии с которой оценивались потенциальные исполнители заказов министерства обороны, занималась фирма Software Engineering Institute. В основу модели положен анализ процессов, выполняемых при разработке ПО, с учетом связанных с ними рисков.

Прообразом модели стала анкета, разработанная в 1987 году и содержащая всего 85 процессных и 16 технологических вопросов. По результатам ответов определялась принадлежность компании к одному из уровней зрелости. Со временем концепция уровней зрелости оставалась неизменной, но менялось число областей и их суть.

Уровень зрелости - итоговый показатель оценки по модели CMMI. Всего в модели представлено пять следующих уровня зрелости:

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

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

Третий уровень - определенный уровень. Все процессы описаны на уровне организации (но не на уровне отдельного проекта). Становится видимой внутренняя сторона черных ящиков.

Четвертый уровень - количественно-управляемый. Определенные процессы контролируются с помощью различных средств контроля. Самое главное отличие от третьего уровня - предсказуемая эффективность и управление ею с помощью средств контроля.

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

Кроме уровней зрелости, в методике есть понятие процессной области. CMMI состоит из 22 процессных областей, каждая из которых при внедрении задает цель. Некоторые из целей уникальны, некоторые применимы к нескольким областям, и таким образом их можно разделить на специальные и уникальные. Для достижения различных целей существуют практики, подразделяющиеся на общие и специальные. Список областей следующий:

· Менеджмент требований - управление требованиями к продуктам проекта.

· Планирование проекта - разработка и поддержание планов проекта.

· Мониторинг и контроль проекта - отслеживание стадий протекания проекта и корректировка в случае отклонения от плана.

· Измерение и анализ - поддержка измеримости услуг.

· Оценка качества товаров и процессов - управление качеством в соответствии с продуктом/товаром.

· Менеджмент договоров с поставщиками - управление внешними поставщиками.

· Конфигурационный менеджмент - контроль за целостностью продукции при обновлении и изменении.

· Разработка требований - сбор и анализ требований заказчиков к продукции.

· Техническое решение - разработка решений в соответствии с требованиями и их внедрение.

· Интеграция продукта - эксплуатация, проверка интеграции и функционирования введенного продукта.

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

· Валидация - соответствие продуктов использованию.

· Фокусирование на процессах организации - использование и понимание процессов в соответствии с областями деятельности.

· Описание процессов организации - установление и поддержание процессов организации.

· Организационный тренинг - повышение уровня знаний и развитие способностей людей для эффективного выполнения своих ролей.

· Менеджмент интеграции проектов - взаимодействие заинтересованных лиц при интеграции процесса.

· Менеджмент рисков - анализ возникновения чрезвычайных ситуаций до их возникновения.

· Интегрированные команды - формирование команд для разработки.

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

· Анализ решений и разрешение - анализ альтернативных решений и разработка наиболее подходящего решения на основе структурированного подхода.

· Организационная среда для интеграции - инфраструктура для процессов и интеграции продукта.

· Производительный организационный процесс - поддержание производительности процессов на эффективном уровне.

· Количественный менеджмент проекта - количественное управление определенным процессом в целях достижения качества и производительности.

· Организационные инновации и внедрение - анализ и выбор необходимых инноваций для внедрения.

· Анализ причин и разрешение - выявление причин дефектов и принятие превентивных мер по предотвращению их в дальнейшем.

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

1.3.8 eSourcing Capability Model for Service Providers (eSCM-SP)

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

На рисунке 1.5 представлены основные направления: Sourcing life-cycle (стадии жизненного цикла), Capability levels (уровни способностей), Capability areas (область способностей) и 84 различных процесса, распределенных в соответствии с направлениями.

Рисунок 1.5 - Структура eSCM-SP

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

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

Существует пять уровней областей предоставления ИТ-услуг, поддерживающих следующие уровни зрелости организации:

· первый уровень - непосредственное предоставление услуг;

· второй уровень - наличие процедур, предоставляющих возможность соответствовать требованиям клиентов;

· третий уровень - организация полостью управляет своей работой;

· четвертый уровень - организация внедряет различные инновации;

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

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

1.3.9 SixSigmaR

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

В основу концепции заложены следующие основы:

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

· ключевые показатели эффективности должны быть измеряемыми, контролируемыми и улучшаемыми;

· вовлеченность персонала для совершенствования качества продукции;

· клиентоориентированность;

· управление данными, факторами и показателями;

· постоянное совершенствование бизнес-процессов;

· взаимосвязанное взаимодействие внутри организации.

Для совершенствования процессов в SixSigmaR существует методика DMAIC (define - определение, measure - измерение, analyze - анализ, improve - улучшение, control - контроль), согласно которой процессы компании проходят через 5 этапов уровня зрелости.

Вывод: SixSigmaR позволяет обеспечивать выполнение управления производством на основе используемых стандартов, методик и практик. Использование возможно на определенном уровне зрелости

1.3.10 ISO 15504 или SPICE (Software Process Improvement and Capability Determination)

SPICE - эталонная модель, определяющая измерение процесса и измерение возможностей.

Модель разделена на процессы из пяти категорий: поставщик-потребитель, инжиниринг, поддержка, управление, организация.

Для измерения возможностей используется 5 уровней:

ь 5 уровень - оптимизированный процесс;

ь 4 уровень - предсказуемый процесс;

ь 3 уровень - установленный процесс;

ь 2 уровень - управляемый процесс;

ь 1 уровень - выполняемый процесс;

ь 0 уровень - неполный процесс.

Возможности процессов измеряются с помощью следующих атрибутов:

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

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

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

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

· развертывание процесса;

· измерение процесса;

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

· нововведения в процесс;

· оптимизация процесса.

· Not achieved (0 - 15%) - Не достигнуто.

· Partially achieved (>15% - 50%) - Частично достигнуто.

· Largely achieved (>50%- 85%) - В значительной степени достигнуто.

· Fully achieved (>85% - 100%) - Полностью достигнуто.

В стандарте описаны модель оценок в соответствии со следующими стандартами: ISO/ IEC 12207, ISO/ IEC 15288.

Вывод: Стандарт ISO/ IEC 15504 является одним из вспомогательных элементов способных обеспечить качественное предоставление ИТ-услуг.

1.3.11 ISO/ IEC 19770-1

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

Основа стандарта - четырехуровневый подход к внедрению ПО (рисунок 1.6):

Рисунок 1.6 - Четыре уровня ISO/IEC 19770-1

В стандарте описаны процессы, необходимые для достижения каждого уровня к оптимизации процессов. На рисунке 1.7 показан пример требуемых процессов для достижения необходимых оптимизационных показателей.

Рисунок 1.7 - Требуемые процессы для достижения оптимизации бизнес-процессов

Вывод: Стандарт позволяет обеспечить оптимизационные задачи на основе уровней зрелости организации в соответствии с учетом применения методологий и подходов.

1.3.12 ISO 38500

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

ISO/ IEC 38500 относится к управлению текущего и будущего использования ИТ организации, включая процессы и решения, связанные с текущим и будущим использованием ИТ-управления. Эти процессы могут контролироваться специалистами ИТ в рамках организации, внешними поставщиками услуг или бизнес-подразделениями в рамках организации.

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

Стандарт ISO/IEC 38500 обеспечивает соответствие деятельности организации обязательствам (законодательству, нормативным актам и контрактным соглашениям), обеспечивая при этом эффективное использование ИТ.

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

Структура стандарта ISO/IEC 38500:2008 содержит три раздела:

· область применения и цели стандарта, его применение;

· фреймворк хорошего корпоративного ИТ-управления;

· руководство по корпоративному ИТ-управлению.

Стандарт устанавливает шесть принципов корпоративного ИТ-управления:

· Ответственность (Responsibility). Ответственность сотрудников в организации в отношении потребления и предоставления ИТ-сервисов.

· Стратегия (Strategy). Учет современной и будущей стратегии и их связи с ИТ.

· Приобретение (Acquisition). Анализ поставщиков.

· Реализация (Performance). Поддержание и обеспечение качественного уровня услуг.

· Соответствие (Conformance). Соответствие ИТ законодательству и прочим нормативным актам.

· Поведение (Human Behaviour). Учет деятельности и нужд людей в ИТ-сфере.

В стандарте устанавленго три задачи управления для руководства организации в отношении ИТ:

· Оценка(evaluate) потребности в использовании информационных технологий.

· Направление (direct) планов и политики в сфере ИТ в соответствии с бизнес-целями.

· Контроль (monitor) соответствия политикам и исполнения планов.

Для повышения эффективности управление ИТ должно происходить логично и последовательно. Модель корпоративного управления ИТ (EDM - Evaluate -- Direct -- Monitor), отличается от привычного цикла PDCA.

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

1.4 Анализ методов моделирования диаграмм бизнес-процессов

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

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

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

ИТ-процессы представляют собой бизнес-модель, которая является их формализованным описанием, отражающим существующее положение дел (или модель AS-IS «как есть»), но также она может устанавливать новые усовершенствованные способы осуществления деятельности (или модель AS-TO-BE «как будет»). В связи с этим под целями бизнес моделирования подразумевают возможность обеспечения понимания структурных взаимосвязей внутри организации, а также происходящих процессов. Посредством бизнес-моделирования обеспечивается возможность отображения текущих проблемных зон организации с примерными путями их решения. Создаются условия для формирования требований к возможному планированию по внедрению в структуру организации ИТ-сервисов.

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

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

При объектно-ориентированном подходе корпоративная информационная система разбивается на объекты, взаимодействующие между собой посредством посылки сообщений.

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

Основу многих современных методологий проектирования диаграмм бизнес-процессов составляют:

· методология SADT (Structured Analysis and Design Technique) (IDEF0) - метод функционального моделирования;

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

· моделирование потоков данных DFD;

· метод ARIS;

· метод моделирования, используемый в технологии RUP (Rational Unified Process).

1.4.1 Применение SADT (IDEF0)

Метод SADT (Structured Analysis and Design Technique) является классическим вариантом процессного подхода к управлению. В основу его принципа заложено структурирование деятельности организации в соответствии с ее бизнес-процессами, а не по тому как разработана штатная структура организации. Бизнес-процессы, протекающие внутри корпоративной информационной системы, выделяющиеся методом SADT и несущие в себе определенную ценность для организации должны оптимизироваться в первую очередь. Так же стоит упомянуть о том, что любой бизнес-процесс несет в себе информацию о том кому он предназначается и от кого он идет.

Метод SADT представляет собой совокупность правил и процедур, предназначенных для построения функциональной модели объекта какой-либо предметной области.

Функциональная модель SADT отображает функциональную структуру объекта, т.е. производимые им действия и связи между ними.

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

1.4.2 Применение IDEF3

Подобные документы

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

контрольная работа , добавлен 20.02.2016


Подходы к определению понятия "моделирование бизнес-процессов". Классификация бизнес-процессов. Стандарт функционального моделирования IDEF0. Стандарт динамического моделирования IDEF2. Стандарт моделирования процессов IDEF3–IDEF14 и потоков данных DFD.

контрольная работа , добавлен 11.06.2010


Сущность бизнес-процессов и основные качественные и количественные критерии их оптимизации. Сравнительный анализ методологий моделирования бизнес-процессов, выбор программного средства на примере УУПП "Автоконтакт" ВОС; принцип автоматизации управления.

дипломная работа , добавлен 18.12.2012


Целесообразность внедрения процессного управления на ООО "Мир Алюминия". Разработка рекомендаций и механизма оптимизации основных бизнес-процессов как пути совершенствования системы управления на исследуемом предприятии. Моделирование бизнес-процессов.

дипломная работа , добавлен 08.01.2012


Характеристика взаимосвязи групп бизнес-процессов: основные, обеспечивающие и управления. Определение цели стратегического менеджмента как планирования поведения фирмы в отношении финансов, клиентов, бизнес-процессов, обучения и личностного роста кадров.

реферат , добавлен 12.09.2011


Исследование методологий описания бизнес-процессов, особенности оценки их эффективности. Информационные технологии моделирования бизнес-процессов. Разработка мероприятий по совершенствованию бизнес-процессов на примере швейной фабрики ООО "Бостон".

дипломная работа , добавлен 29.06.2015


Эффективное внедрение процессного подхода. Основные виды бизнес-процессов. Вопросы управления бизнес-процессами. Проект реинжиниринга бизнес процессов организации. Общая характеристика организации ООО "Мир стекла". Разработка бизнес-процесса организации.

курсовая работа , добавлен 17.11.2014


Понятие бизнес-моделирования. Анализ финансово-хозяйственной деятельности компании ЗАО "Ясень"; разработка бизнес-процессов производства, их оптимизация и повышение эффективности работы предприятия с внедрением программного продукта "1С:Молокозавод".

дипломная работа , добавлен 15.09.2012


Описание системы моделирования: обзор аналогичных систем, определение конвейерного бизнес-процесса, язык моделирования, редукция конвейера. Разработка методологии проектирования. Анализ проблем бизнеса и определение требований. Спецификация проекта.

дипломная работа , добавлен 07.07.2012


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

Концепция управления качеством информационных услуг (Information Technology Service Management - ITSM) возникла в результате принципиального изменения сегодняшней роли ИТ-подразделений. Бизнес-процессы настолько тесно увязаны с приложениями, техническими ресурсами и деятельностью персонала отделов автоматизации, что эффективность последних оказывается одним из решающих факторов эффективности компании в целом.

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

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

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

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

Итак, ITSM подразумевает коренную реорганизацию службы эксплуатации информационных технологий. Опираясь на мировой опыт, компания Нewlett-Рackard разработала типовую модель управления качеством информационных услуг, так называемую ITSM Reference Model. Модель детально описывает процессы и взаимосвязи между ними, которые должен поддерживать ИТ-отдел, чтобы предоставлять информационные услуги с гарантированным качеством.

Ключевые элементы ITSM - процессы, персонал, технологии

Идеология ITSM держится на трех китах:

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

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

Типичные примеры ИТ-процессов - установка нового ПО, ликвидация проблем в сети, процесс перехода на новую резервную систему и т.д. Нечетко определенные и недокументированные процессы неизбежно станут источником незапланированных и, следовательно, неконтролируемых изменений в ИТ-инфраструктуре. Это приведет к большому числу переделок, дублированию функций, периодическим простоям и в конечном итоге к нерациональному использованию ресурсов, увеличению времени восстановления после сбоев и недовольству пользователей. А для бизнеса компании в целом, особенно если он уже успел обзавестись приставкой «е», последствия могут оказаться просто катастрофическими. Так, например, случилось с крупнейшим интерактивным аукционом eBay, который почти сутки находился в нерабочем состоянии из-за проблем с программным обеспечением. Это сразу почувствовали его клиенты во всем мире, а акции eBay подешевели суммарно на 5 млрд. долл., зато заработали конкуренты, ведь расстояние до конкурента на электронном рынке равно одному щелчку клавиши мыши.

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

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

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

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

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

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

Типовая модель

Два года назад Hewlett-Packard предложила типовую модель информационных технологий HP IT Reference Model, которая позволяет разработать структуру ИТ-процессов в компании и на ее основе реализовать управление качеством информационных услуг. Типовая модель представляет собой методику внедрения лучшего международного опыта в области ИТ, собранного в Библиотеке IT Infrastructure Library. Библиотека ITIL - это сборник из 68 книг по различным областям функционирования ИТ, включая планирование ресурсов, управление проблемами, управление инцидентами, разработку и внедрение новых услуг, снижение расходов, управление пользователями и т.д. Эта информация собиралась и систематизировалась Комитетом по телекоммуникациям при правительстве Великобритании, а сейчас поддерживается, издается и обновляется независимой организацией EXIN .

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

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

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

Гарантии предоставления услуг

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

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

Процесс управления конфигурациями (configuration management) регистрирует и контролирует данные об ИТ-инфраструктуре. Этот процесс обрабатывает информацию о каждом элементе конфигурации (configuration item - CI): атрибуты CI (системы и сетевые устройства, прикладные программы, персонал, документация и т.д.), статус CI (в наличии, в ремонте, в производственной среде и т.д.) и взаимосвязи между ними (например, «компьютер А находится на рабочем столе пользователя X», «принтеры В, C и D доступны для использования» и т.д.). Процесс управления конфигурацией, который относится только к ресурсам ИТ-инфраструктуры, не следует путать со стандартной процедурой управления ресурсами предприятия. Любые процессы, влияющие на инфраструктуру (а это все процессы модели), будут взаимодействовать с процессом управления конфигурацией.

Привязка ИТ к бизнес-процессам

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

В ходе анализа бизнес-процессов (business assessment) исследуется рынок ИТ-услуг и определяются бизнес-требования к ИТ-отделу. Процесс управления пользователями (customer management) позволяет ИТ-отделу выступить в роли полноправного бизнес-партнера для потребителей информационных услуг. Управление пользователями - это возможность прогнозировать их потребности, продавать ИТ-услуги, измерять степень удовлетворенности заказчика предоставленной ему услугой. Процесс управления пользователями взаимодействует с другими процессами «бизнес-группы». Информация о пользователях, полученная в ходе выполнения этого процесса, может использоваться при анализе рынка и конкурентной ситуации, а результаты анализа бизнес-процессов и данные о пользователях в свою очередь являются основой для разработки ИТ-стратегии.

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

Управление услугами

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

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

Понятие требуемого уровня предоставляемой услуги, которое может включать перечень приложений на рабочих местах, время отклика компьютерных систем, время исправления неисправностей и т.д., является важнейшей составляющей управления информационными услугами и поддерживается процессом управления уровнем услуг (service level management). В ходе этого процесса на основе заданных параметров стандартной услуги и оценок ее стоимости определяется, обсуждается с заказчиком, отслеживается и фиксируется в отчетах необходимый заказчику уровень услуг. Подробные спецификации услуг, полученные в результате выполнения процесса планирования услуг, являются отправной точкой для заключения осмысленных соглашений SLA.

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

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

Процесс управления ресурсами (capacity management) осуществляет контроль за тем, чтобы рабочая нагрузка задействованных компьютерных ресурсов отвечала тем требованиям, которые оговорены в соглашении об уровне услуги. Этот процесс также является поставщиком данных для процесса планирования услуг и управления уровнем услуг.

Процесс снижения расходов (cost management) позволяет определить и контролировать реальную стоимость ИТ-услуги. Этот процесс прогнозирует прибыль от реализации услуги, определяет ее бюджет, анализирует, как используется услуга и соответствует ли она заданной стоимости, выдвигает предложения по совершенствованию услуги с целью снижения расходов, вычисляет и выставляет счета заказчикам. Результаты этого процесса используются процессами планирования услуг и управления уровнем услуг для оценки стоимости услуги, а также процессами «бизнес-группы».

Разработка и внедрение услуг

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

Процесс реализации и тестирования (build&test) направлен на разработку и одобрение функциональной версии компонента информационной инфраструктуры, функции или услуги в целом. После того как сформулированы спецификации услуги, процесс реализации и тестирования получает нужные компоненты, реализует определенные функции или полномасштабное решение. Когда реализация компонента, функции или услуги завершена, проводится тщательное тестирование. В том числе проверяется соответствие компонентов и услуги принятым стандартам защиты. Процесс реализации и тестирования находится в тесном взаимодействии с процессами управления изменениями, управления конфигурациями и выпуском версии продуктивной системы.

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

Оперативная поддержка

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

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

Управление инцидентами (incident management) или служба поддержки (Help Desk) - процесс быстрого восстановления готовности услуги с наименьшими потерями в случае возникновения инцидентов в инфраструктуре. Служба поддержки обрабатывает звонки пользователей, регистрирует информацию о сбое, определяет приоритеты разрешения инцидентов. Управление инцидентами предполагает повседневное взаимодействие потребителя и поставщика услуги, являясь ценным источником информации о том, насколько пользователь удовлетворен ИТ-обслуживанием.

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

Реализация ITSM

Достоинство Типовой модели НР в том, что она не имеет определенных точек начала или конца; внедрение ITSM на ее основе можно начинать с любых процессов. Но есть несколько вариантов, которые наиболее типичны, поскольку помогают организациям быстро справиться со своими проблемами.

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

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

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

ITSM - новая для ИТ-отделов концепция. Но ее необходимость диктуется жизнью. Слишком велика сегодня роль информационных технологий для бизнеса, особенно для его «е»-компонента. То, что в Hewlett-Packard активно занялась этой проблемой, конечно, не случайно: технологическая основа для автоматизации работы ИТ-отдела - это платформа управления компьютерными системами и сетями HP OpenView ( , «Открытые системы», 2000, №7-8). Входящий в нее компонент IT Service Manager использует концепцию процессов и является обязательным компонентом проектов НР при развертывании ITSM-решений IT Service Manager интегрирован с другими компонентами OpenView, которые обеспечивают управление уровнем услуг, сбоями, проблемами, изменениями, позволяют взглянуть на информационные ресурсы с точки зрения бизнес-процессов и т.д. Внедрение ITSM-решений на основе Типовой модели и платформы OpenView в HP начали с себя, реорганизовав работу собственного ИТ-подразделения в соответствии с концепцией управления качеством информационных услуг.