Предисловие (стр. 80 )

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

Особой сферой ответственности процесса управления релизами является библио­те­ка эталонного ПО (англ. Definitive Software Library, DSL). Эта библиотека является физическим хранилищем протестированных и подготовленных к распространению копий разработанного и покупного ПО, лицензий на последнее, а также пользовательс­кой и эксплуатационной документацией. Информация о копиях ПО, хранящихся в DSL ведется в базе данных позиций конфигурации (рис. 15.14). Наличие такой библиотеки играет важную роль в процессе управления релизами, особенно на этапе распространения и установки ПО.

Рис.15.14. Взаимодействие DSL и CMDB.

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

Планирование релиза;

Проектирование, разработка, тестирование и конфигурирование релиза;

Подписание релиза в развертывание;

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

Аудит оборудования и ПО до начала внедрения изменений и по завершении такового;

Размещение эталонных копий ПО в DSL;

Установка нового или усовершенствованного оборудования и ПО;

Постоянное улучшение процесса.

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

15.3.5. Размер организации и применимость модели ITIL/ITSM

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

В небольшой службе ИС (типичная численность – 1-5 человек42) ITIL/ITSM выполняет двоякую роль: с одной стороны, обеспечивается последова­тель­ное применение подхода к управлению службой ИС как к управлению сервисами ИТ, с другой – фиксирует задачи службы ИС и ответственных за них сотрудников. Независимо от своей численности служба ИС должна решать задачи предоставления сервисов, сопровождения сервисов, интеграции в основной бизнес, управления приложениями и управления инфраструктурой ИТ. При этом малая численность сотрудников и совмеще­ние большого числа ролей позволяют решать задачи управления службой при минималь­ной формализации процесса. Обычно бывает достаточно обсудить с руководством организации и кратко зафиксировать основные политики управления уровнем сервиса, управления инцидентами и управления изменениями. В качестве программного обеспечения на этом уровне вполне достаточны стандарт­ные офисные пакеты.

Следующий уровень – уровень формализованных процессов (типичная чис­ленность службы ИС – 10-30 человек). В этом случае в службе ИС появляются внутренние политики, зафиксированные письменно и регулирующие исполнение основных ролей. При развитом использовании модели ITIL/ITSM на этом уровне появляется также формальное соглашение об уровне сервиса (подробно описано в следующем параграфе). На этой стадии появляется спе­циализированное программное обеспечение управления рабочими станциями пользователей и какое-либо ПО, позволяющее вести журнал обращений пользова­телей в Service Desk и БДПК. То и другое ПО может быть как стандартным, например, про­дуктами семейства HP OpenView, так и самостоятельно разработанным, напри­мер, средствами MS Office.

Наконец, высший уровень – уровень автоматизированных бизнес-процес­сов (служба ИС свыше 30 человек). В этом случае эффективное использование ITIL/ITSM, как и любой другой модели управления невозможно без специализированного ПО анализа корпоративной сети, сбора данных об оборудо­вании и ПО на клиентских рабочих местах и удаленном управлении последними, ПО Service Desk и БДПК. В ITIL/ITSM в этом качестве используются разнообразные семейства программных про­дуктов от различных поставщиков. Соответственно уровню автоматизации повышаются требования к формализации бизнес-процессов службы ИС. Форма­лизации также способствует весьма вероятное на этом уровне использование услуг внешних консультантов и/или услуг аутсорсинга.

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

15.4. Соглашение об уровне сервиса (СУС) как основа управления сервисами ИТ

На основании простого описания процессов ITIL/ITSM СУС может показаться малозначительным документом, задействованным в одном из процессов модели. Между тем именно СУС придает рыночный или квазирыночный характер взаимоотношениям между службой ИС и бизнес-подразделениями, вследствие чего оно ока­зывается центральным звеном процесса управления сервисами ИТ. Для повседневной деятельности службы ИС характерна неоднозначность оценок, исходящих от различных функциональных служб организации. К примерам такой неоднозначности можно отнести:

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

Оценку результатов внедрения новой информационной системы – здесь предметом различий станет соответствие системы потребностям конечного пользователя;

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

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

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

То и другое условие выполняются при наличии в организации СУС – соглашения об уровне сервиса. Каким именно способом это достигается, будет показано в данном параграфе.

15.4.1. Система формальных соглашений и процедур в управлении сервисами ИТ

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

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

План повышения качества сервиса (англ. Service ­Improvement Plan) – внутренний документ службы ИС, описываю­щий возможные источники нарушений сервиса и меропри­ятия по их предот­вращению и устранению. Для внешних поставщиков оборудования, ПО и услуг мероприятия, предусмотренные планом, должны быть включены в контракты.

Соглашение об уровне внутренней поддержки (СУВП, англ. Operation Level Agreement, OLA) – внутренний документ службы ИС, регла­ментирующий взаимодействие функциональных подразделений и ролей процессов в процессе разработки сервисов и оказании услуг бизнес-пользователям.

В свою очередь СУС состоит из следующих основных частей:

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

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

Описания отчетности и механизма контроля выполнения соглашения сторо­нами.

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

Реквизитов договора – номера договора, номера версии, подписей сторон и т. д.

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

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