Окружающая среда

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

Основные модели реализации методологии ITIL. Соглашение об уровне сервиса SLA в управлении ИТ на предприятии

Понятие бизнес-процесса информационной службы. Модели бизнес-процессов информационной службы. Роль и акценты ИТ сервисов в управлении бизнесом. Базовая методология управления ИТ-инфраструктурой Information Technology Infrastructure Library (ITIL).

Тема 16. Методология ITIL управления функционированием информационных систем

Хорошенько поймите, чего вы хотите! А затем – только следите, чтобы это делалось наилучшим и самым дешевым способом»

В настоящее время общепризнанным фактом является то, что информационная технология как таковая не приносит финансовой отдачи. Поэтому для оценки дохода от использования информационной системы необходимо рассматривать деятельность компании не только с точки зрения технологии, но и с точки зрения выполняемых пользователями задач, организации работ, обрабатываемых документов и данных. Бизнес-процесс как категория анализа как раз и позволяет рассматривать всю совокупность этих аспектов, т.е. расчет дохода от использования КИС необходимо производить с точки зрения выполняемых пользователями задач обработки данных – бизнес-процессов.
Одно из определений бизнес-процесса является следующее:
бизнес-процесс – описание последовательности работ, направленной на достижение определенной бизнес-цели, обладающее следующими признаками:
– интегрированное описание функций, документов, опосредующих эти работы, и организационных подразделений;
– иерархический характер описания.
Характеристики процесса:
– процесс может быть представлен в виде блок-схемы;
– производительность процесса может быть измерена;
– процесс может быть улучшен путем выявления соотношений между его компонентами и последующим изменением этих компонентов и их взаимосвязей.
Примеры основных бизнес-процессов: разработка продукции, закупка материалов, производство.
Примеры обеспечивающих бизнес-процессов: бухгалтерский учет, финансы, информационные технологии.
В качестве типовой модели бизнес-процессов информационной службы используется модель ITIL, признанную на сегодняшний день в отрасли фактическим стандартом бизнес-процессов. В ряде случаев – например, при описании бизнес-процессов, не охваченных моделью ITIL, – используется модель ITSM (коммерческая реализация ITIL, разработанная компанией Hewlett-Packard).

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

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

Для ориентации в Библиотеке ее условно разбили на пять разделов:

5. "Управление Инфраструктурой" (Manage the Infrastructure).

К тому "Бизнес-перспектива " отнесены проблемы, связанные с качеством создаваемых ИТ-сервисов как неотъемлемой части всего бизнеса, в частности:

· преобразование бизнеса в ходе радикальных изменений.

Том "Предоставление ИТ-сервисов" посвящен вопросам обеспечения адекватности предоставляемых сервисов реальным потребностями бизнеса:

· Управление непрерывностью предоставления сервисов;

· Управление взаимоотношениями с клиентами.

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

Том "Управление информационной и телекоммуникационной инфраструктурой" содержит:

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

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

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

· устанавливается связь инцидента с процессом "Управления инцидентами";

· инцидент учитывается в процессе "Управления проблемами"; при дальнейшем анализе возможны обращения к процессам "Управления возможностями" и "Управления уровнями сервиса";

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

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

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

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

· процесс "Управление доступностью" обязательно должен произвести со своей стороны оценку изменений в оборудовании и программном обеспечении;

· процесс "Управление конфигурациями" должен зафиксировать действующее состояние (для возможности возврата) и новую конфигурацию в Базе данных конфигурационных единиц (CMDB);

· процесс "Управления взаимоотношением с клиентами" должен поддерживать связь с клиентом для его полного и своевременного информирования о прогрессе в разрешении его проблемы.

Появление концепции ITSM (Information Technology Service Management) обусловлено особой ролью ИТ в современном бизнесе: новые информационные технологии тесно вплетаются в традиционные сферы деловой активности, в числе прочего, затрагивая компании, весьма далекие от вопросов автоматизации. Сегодня очень важно организовать работу ИТ-служб таким образом, чтобы она гармонично вписалась в культуру и методику самого бизнеса. Иными словами, механизм предоставления информационных услуг необходимо четко описать в терминах бизнес-процессов, сделать его прозрачным и понятным тем сотрудникам, которые не являются специалистам в области ИТ, и при этом учесть стоимость ИТ-услуг. Тем самым, отправной точкой как для ITSM в целом, так и для любого проекта внедрения данной методологии становится бизнес-проблематика. В подавляющем большинстве случаев она связана с требованием повышения эффективности работы ИТ-служб. Терминология ITIL Проблему определения терминов усложняет относительная новизна для отечественных ИТ-профессионалов как самой идеи перехода ИТ-департамента от управления ИТ-ресурсами к управлению поддержкой предоставления услуг, так и специфика предметной области, охватывающей всевозможные системы управления ИТ. Ярким примером разных понятий можно считать предложенное Hewlett-Packard жесткое различение заявок на обслуживание(Service Call) и инцидентов (Incident). Под инцидентами понимаются сбои, зафиксированные автоматизированными системами мониторинга и контроля ИТ-инфраструктуры, а под заявками на обслуживание — обращения конечных пользователей. Заявки могут быть разных типов, в том числе «запросами на устранение инцидента» или просто «инцидентами». При этом, с точки зрения компании, заявка на обслуживание «типа инцидент» и просто «инцидент» — совершенно разные понятия. В ITIL же используется иная классификация, в которой понятие «заявка на обслуживание» напрямую не определено, зато есть понятие запрос на обслуживание как подмножество понятия «инцидент». Соответственно, сам «инцидент» в ITIL определяется иначе, чем в HP ITSM. Основная причина несоответствия, по-видимому, кроется в том, что Hewlett-Packard подходит к рассматриваемым вопросам с точки зрения поставщика. Недавно вышла третья версия библиотеки — ITIL v3, которая предлагает новый взгляд на то, как сделать сервис рабочим инструментом ИТ-подразделения. Методология библиотеки ITIL v2 сформировала взгляд на ИТ-подразделение как на поставщика сервисов для бизнеса. Сервисы — это и рабочее место пользователя, и электронная почта, и печать, и доступ к информационным системам. Перечень сервисов фиксируется в виде Каталога, условия предоставления каждого сервиса документируются в SLA — соглашении об условиях предоставления сервиса. Достигнуто понимание, что от комплексной работоспособности всех ИТ-компонентов, составляющих сервис, зависит эффективность ИТ-поддержки бизнес-деятельности пользователей. Автоматизированная поддержка ИТ-сервисов становится таким же непременным условием, как и автоматизированная бухгалтерия. На рынке представлен большой класс специализированного программного обеспечения для управления ИТ-сервисами. Как и предыдущая версия, ITIL v3 базируется на сервисном подходе к деятельности ИТ-службы, однако теперь логику ИТ-процессов задает жизненный цикл сервиса. Для управления сервисом на каждом этапе его жизненного цикла, от разработки до аннулирования, вводится соответствующая группа процессов. В соответствии с этим в ITIL v3 добавлены 12 новых процессов, новые функции и объекты, метрики и показатели ценности сервисов для бизнеса. В соответствии с ITIL v3 поддержка жизненного цикла сервисов включает следующие виды деятельности: 1. моделирование сервисов (с использованием процессов управления активами и конфигурациями); 2. создание и визуализация связей между ИТ-системами и конфигурационными единицами, формирующими сервис; 3. публикация описаний сервисов в Каталоге сервисов; 4. определение поддерживаемого уровня сервисов; 5. настройка функции запроса сервисов сотрудниками бизнес-подразделений; 6. исполнение запросов на сервисы (с использованием процессов управления изменениями, управления запросами); 7. отслеживание жизненного цикла предоставляемых сервисов — от запросов до введения в действие и аннулирования; 8. мониторинг работоспособности ИТ-компонентов и поддержка сервисов (с использованием процессов управления инцидентами, изменениями, проблемами); 9. измерение и анализ параметров предоставления сервисов; 10. оптимизация (модернизация) сервисов. Анализ изменений библиотеки ITIL v3 дает основание сделать вывод: перегруппировка и расширение тем позволяют лучше согласовать ИТ-процессы и операции с результатами бизнеса, для достижения которых они предназначены, и перейти к поддержке сервисов с жизнеспособной оценкой стоимости и запланированной актуализацией. Сущность методологии управления ИТ-услуг заключается в том, что имеющиеся в организации информационные системы и службы их эксплуатации рассматриваются в комплексе, как предоставляющие свои услуги сотрудникам организации — пользователям в виде конечных услуг. Кроме того, все службы управляют количеством, качеством и развитием услуг для каждого пользователя. Одним из основных элементов такого комплекса является диспетчерская служба (Service Desk, Help Desk, Call Center и т.д.). Использование ITSM позволяет экономно расходовать ресурсы для поддержки ИТ-услуг в организациях любых масштабов и структур. Одним из ключевых моментов внедрения методологии ITSM является использование рекомендаций, изложенных в библиотеке передового ИТ-опыта ITIL (Information Technology Infrastructure Library). Эти рекомендации содержат описание возможных методов и средств внедрения и реализации процессов функционирования ИТ-служб, а также взаимосвязей между этими процессами. Внедрение ITSM осуществляется поэтапно; на каждом этапе в рамках соответствующего проекта может внедряться один или несколько процессов. Существует три типовых варианта начала внедрения: с процесса «Управление инцидентами»; с процесса «Управление уровнем услуг«; с процесса «Управление конфигурациями». Факторы, влияющие на внедряемый процесс Один из важных этапов внедрения процесса «Управление инцидентами» — разработка модели реализации данного процесса в будущем (модель «как будет»), которая включала формирование структуры ЦДС и алгоритма деятельности ее сотрудников при реализации процесса «Управление инцидентами».

Рис.1 Жизненный цикл инцидента согласно ITIL

В соответствии с ITIL алгоритм реализации данного процесса базируется на жизненном цикле инцидента (рис. 1), а сам процесс должен быть одной из основных функций ЦДС. В связи с этим при разработке модели «как будет» были учтены факторы, влияющие на структуру ЦДС и на деятельность ее сотрудников. К таким факторам ITIL рекомендует относить, в частности:

· реальный и требуемый бюджет организации;

· масштаб и структура организации;

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

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

· текучесть кадров;

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

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

Рис.2 Обобщенная схема воздействия факторов,влияющих на процесс "Управление инцидентами"

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

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

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

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

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

· выбираются метрики, описывающие деятельность предприятия (например: финансовая, экономическая, кадровая, технологическая и т.д.);

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

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