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

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

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

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

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

Под понятием релиз подразумевается набор новых или/и измененных конфигурационных единиц, которые могут вместе испытываться и внедряться в рабочую ИT среду. Релиз определяется RFC (запрос на изменения), для исполнения которого он внедряется в работу.

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

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

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

Главным предназначением процесса управления релизами является полное обеспечение качества продуктивной среды вследствие использования формальных процедур, тестов и проверок при вводе в эксплуатацию новых релизов и версий. Главным отличием от процесса управления изменениями, который в первую очередь занимается верификацией, процесс управления релизами осуществляет процедуру внедрения. Управление релизами выполняется в сотрудничестве с управлением конфигурациями и управлением изменениями, что обеспечивает своевременное обновление единой базы CMDB (база данных управления конфигурациями) с учетом каждого внедряемого релиза. Управление релизами обеспечивает обновление контентного содержания релиза (программного кода) в DSL - библиотека эталонного программного обеспечения. При помощи базы CMDB еще отслеживается спецификация аппаратных средств, инструкции, руководства по инсталляции, установке, внедрению, также сетевые конфигурации и т.д. Весь запас аппаратной части, в том числе стандартные базовые конфигурации, хранятся на специальном складе эталонного аппаратного обеспечения, который называется DHS. Главным объектом, на который направлена деятельность процесса управления релизами в первую очередь является ПО.

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

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

ь выполнение большого количества одинаковой работы из-за наличия копий программного обеспечения различных версий;

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

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

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

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

Требования

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

2. Обеспечение гарантии того, что каждый пакет для релиза включает в себя набор взаимосвязанных и совместимых между собой компонентов;

3. Управление релизом и его компонентами, координация действий, обусловленных процессом внедрения программного обеспечения;

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

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

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

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

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

Задачи

o Создание планов, обеспечение координации, внедрение аппаратно- программных средств.

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

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

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

o Определение качественного и количественного состава релизов, а также планирование их внедрения при участии процесса Управления Изменениями.

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

o Надежность оригинальных копий программ в используемой организацией Библиотеке эталонного программного обеспечения (DSL), а также регулярного обновления базы данных управления конфигурациями CMDB; то же касается аппаратных средств на складе DHS.

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

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

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

• Контроль и отслеживание потоков инвестиций в ПО, от которых сильно зависит развитие бизнеса.

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

• Уменьшение вероятности возникновения дефектов, инцидентов и ошибок в результате политики тестирования и контроля внедрения.

• Обучение бизнес пользователей и привлечение их к участию в непосредственном тестировании релизов.

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

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

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

Процесс управление релизами первостепенно отвечает за выпуск новых релизов и их наиболее эффективное и корректное использование заказчиками/бизнес-пользователями.

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

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

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

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

· Рациональное и правильное использование среды тестирования и сборки;

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

· Четкое использование методик тестирования, принятое в компании;

· Контроль входов и выходов этапа сборки и тестирования;

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

· Стандартизация;

· Проверка требований по информационной безопасности и контроль доступа к компонентам ПО;

· Проверка готовности релиза к запуску или передаче его на следующий этап;

· Запуск или передача релиза на следующий этап.

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

Функции

- планировать и контролировать успешное развертывание ПО и сопутствующих аппаратных средств;

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

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

- узнавать и учитывать ожидания клиента при планировании и развертывании новых релизов;

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

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

- обеспечивать сохранение мастер-копий всех программ в библиотеке эталонного программного обеспечения (БЭПО) и обновление базы данных управления конфигурациями (CMDB); - обеспечивать безопасность развертывания и изменения всех аппаратных средств, используя услуги управления конфигурациями.

Окружение процесса

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

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

Рисунок 2.2 - Окружение процесса

Управление релизами взаимодействует со следующими процессами:

a) Управление Конфигурациями

Процесс управление конфигурациями занимается регистрацией всех доступных версий программно-аппаратного обеспечения в базе данных управления конфигурациями (CMDB), как базисная конфигурация. Программное обеспечение, поставляемое в библиотеку DSL, а также аппаратное обеспечение для DHS обязательно проходит процедуру регистрации в базе данных управления конфигурациями с согласованием обеспечиваемого уровня детализации. Статус каждой конфигурационной единицы при мониторинге может отражать ход выполнения задачи и выглядеть может так: «в разработке», «готов к тестированию», «в тестировании», «обнаружен дефект», «отклонен», «исправлен» и так далее.

b) Управление Изменениями

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

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

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

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

Метрика	Описание	Задача метрики	Аудитория
Число установленных программных пакетов	В рамках стандартного процесса верификации любое ПО, обнаруженное на любом оборудовании, можно сверить с DSL, установив таким путем, авторизовано ли оно и правильна ли его версия.	контролировать релиз ПО в инфраструктуре, чтобы свести к минимуму число вероятных сбоев.	Владелец процесса, руководство ИТ-отдела, владелец процесса SLA, бизнес- клиент, члены команды, владелец процесса SIP.
Число срочных релизов	Срочные релизы выполняются в рамках соответствующего процесса -- когда он активизируется, этот факт может быть зафиксирован и учтен в данной метрике.	обеспечить эффективное управление релизами с минимальным ущербом для бизнеса.	Владелец процесса, руководство ИТ-отдела, владелец процесса SLA, бизнес-клиент, члены команды, владелец процесса SIP.
Число инцидентов, вызванных новым релизом	В записях о закрытии инцидентов в качестве одной из потенциальных причин должно фигурировать управление релизами. Если фиксируется именно она, это учитывается данной метрикой.	эффективное управление релизами с целью удовлетворения потребностей бизнеса.	Владелец процесса, руководство ИТ-отдела, владелец процесса SLA, бизнес-клиент, члены команды, владелец процесса SIP.
Процент своевременных релизов	Управление релизами включает планирование сроков всех релизов в CMDB. Все изменения этих сроков учитываются данной метрикой.	обеспечить эффективное управление релизами с целью сокращения возможных сбоев в работе компании.	Владелец процесса, руководство ИТ-отдела, владелец процесса SLA, бизнес-клиент, члены команды, владелец процесса SIP.
Число непротестированных релизов	Все релизы должны тестироваться и одобряться, причем обязательно человеком, независимым от автора релиза. Если этого не происходит, такой случай учитывается метрикой.	Показывает число незавершенной работы	Владелец процесса, руководство ИТ-отдела, владелец процесса SLA, бизнес- клиент, члены команды, владелец процесса SIP.
Средние трудозатраты на релиз (часы)	фактические трудозатраты в человеко-часах.	постепенному сокращению трудозатрат на один релиз. В более интеллектуальной среде можно использовать вместо данного показателя разность между прогнозируемым (в плане релиза) и реальным числом человеко- часов.	Владелец процесса, руководство ИТ-отдела, владелец процесса SLA, бизнес-клиент, члены команды, владелец процесса SIP.
Число неиспользуемых лицензий на ПО	Лицензии на ПО, которые не инсталлированы и не подтверждены со стороны процесса управления мощностями	Сокращение количества, используемого нелицензионного или неавторизованного ПО	Владелец процесса, руководство ИТ-отдела, владелец процесса SLA, бизнес-клиент, члены команды, владелец процесса SIP.
Число приложений/ревизий, выпущенных в производство {сборки}	Одобренные релизы	Показатель реальной обеспечиваемой продуктивности, не обязательно связанный с качеством приложения.	Владелец процесса, руководство ИТ-отдела, владелец процесса SLA, бизнес-клиент, члены команды, владелец процесса SIP.
Число дефектов, обнаруженных по журналам регистрации {дефекты}	Число новых ошибок, выявленных самой службой поддержки приложений. Учитываются все ошибки, обнаруженные как по журналу регистрации, так и по другим источникам.	характеризует работу системы решения проблем по выявлению еще не проявившихся ошибок.	Владелец процесса, руководство ИТ-отдела, владелец процесса SLA, бизнес-клиент, члены команды, владелец процесса SIP.
Число ошибок, выявленных при разработке или тестировании {ошибки}	Дефекты, обнаруженные в ПО собственной разработки.	Показывает степень дефектизации приложения	Владелец процесса, руководство ИТ, владелец процесса SLA, члены команды, владелец процесса SIP.
Число ошибок, исправленных при тестировании	Дефекты, зарегистрированные как исправленные и протестированные.	Мера производительности	Владелец процесса, руководство ИТ, владелец процесса SLA, члены команды, владелец процесса SIP
Число ошибок, которые были отклонены	Дефекты, которые были решены путем наладки тестируемой среды или помечены, как нормальное состояние системы	Показатель качества сборки	Владелец процесса, руководство ИТ, владелец процесса SLA, члены команды, владелец процесса SIP
Число дней, потраченных на развертывание приложения	Время отсчитывается согласно числу дней, заранее отведенных на поставку протестированного кода в DSL	успешно соблюдается календарный план при разработке приложений.	Владелец процесса, руководство ИТ, владелец процесса SLA, члены команды, владелец процесса SIP.
Число дней, потраченное на тестирование приложения	Полный срок тестирования приложения	Визуализация скорости работы команды тестирования	Владелец процесса, руководство ИТ, владелец процесса SLA, члены команды, владелец процесса SIP.

Документирование процесса

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

RFC - документ из серии пронумерованных информационных документов Интернета, охватывающих технические спецификации и Стандарты, широко используемые во Всемирной сети. Заглавие «Request for Comments» можно перевести как «заявка на обсуждение», «тема для обсуждения», или «рабочее предложение».

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Задачи

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

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

· Контролировать регистрацию изменений и ошибок.

· Гарантировать соответствие конфигураций требованиям.

· Обеспечить архивирование, сопровождение и восстановление элементов конфигурации.

Функции

· Идентификация конфигураций;

· Аудиты конфигураций;

· Контроль и управление конфигурациями;

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

· Планирование конфигураций.

Окружение процесса

· Управление инцидентами (информация о конфигурационных единицах необходима для регистрации инцидентов и определения какая единица связана с данным инцидентом);

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

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

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

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

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

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

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

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

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

Документирование процесса

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

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

· Головные библиотеки: объекты, необходимые для управления хранением документов;

· Программные хранилища или архивы: общая память, в которой хранятся все программы и документы;

· Технологические библиотеки: предназначены для сохранения всех средств, предусматриваемых применяемой технологией разработки.

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

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

Аутсорсинг в ИT позволяет сократить расходы предприятия, поэтому стремительное развитие рынка ИT-аутсорсинга обусловлено прежде всего тем, что аутсорсинг в сфере ИT позволяет компаниям снизить косвенные затраты (по данным Gartner Group, их сокращение достигает в среднем 30%). Однако не все согласны с этим. По данным различных исследований, в мировой практике не более 75% компаний считают, что использование аутсорсинга позволило им достичь значительной экономии. За последнее время в Европе порядка 40% телекоммуникационных компаний отказались от услуг аутсорсинга информационных технологий по причине несоответствия критерию цена/качество.

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

Чем руководствуются российские компании, стремясь расширить штат ИT-подразделения и возлагая на него все больше функций? Обычно это объясняется следующим:

оперативностью (возможность быстрой реакции на запросы пользователей);

безопасностью (минимизация рисков утечки информации);

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

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

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

Принципы

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

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

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

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

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

Задачи

· Управлять взаимоотношениями с подрядчиками и их производительностью;

· Обсуждать и согласовывать договоры. Совместно с процессом Управления уровнем услуг (SLM). Обеспечивать согласованность договоров и соглашений с потребностями бизнеса и поддержку SLA;

· Управлять договорами на протяжении их жизненного цикла;

· Поддерживать политику работы с подрядчиками и соответствующую базу данных подрядчиков и договоров (Supplier and Contract Database, SCD). Процесс управления подрядчиками позволяет управлять подрядчиками и услугами, которые они оказывают, с целью достижения целевых показателей качества ИТ-услуг и соответствия ожиданиям заказчиков;

· Получение отдачи от вложений в подрядчиков и договоры;

· Совместно с SLM обеспечение того, что внешние договоры и соглашения с подрядчиками соответствуют нуждам бизнеса и поддерживают соблюдение целевых показателей качества, приведенных в SLR и SLA;

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

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

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

· Управление политикой работы с подрядчиками и поддерживающей ее базой данных подрядчиков и договоров (Supplier and Contract Database, SCD).

Функции

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

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

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

Классификация подрядчиков

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

Виды подрядчиков в IT

Виды подрядчиков	Поставщики аппаратно-программных средств	Провайдеры	Проектировщики
Кто?	Вендоры, разработчики	Интернет-провайдеры, телекоммуникационные компании	Системные интеграторы, IT-консалтинг компании
Формат услуг	Разработка, внедрение, тестирование, сопровождение ПО и аппаратного комплекса	Предоставление телекоммуникационных услуг (телефония, интернет, сетевое окружение)	Проектирование и аудит сетевых коммуникаций, архитектуры, базы данных, системы пользовательских приложений, системы безопасности, системы управления (инжиниринг)

Окружение процесса

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

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

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

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

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

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

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

Метрика	Описание	Задача метрики	Аудитория
Средние затраты на предоставление одной услуги	Данные о затратах извлекаются из CMDB: Число обращений х Расчетная стоимость обращения + Управление проблемами + Постоянные издержки и т.д	Оценить суммарную стоимость инцидентов, проблем, изменений и операций, посвященных определенной услуге	Владелец процесса, руководство ИТ-отдела, владелец процесса SLA, бизнес-клиент, члены команды, владелец процесса SIP.
Число инцидентов, связанных с предоставлением услуг подрядчиками	Процесс предоставления услуг должен постепенно сокращать число инцидентов. Чтобы избежать влияния сезонных или иных краткосрочных факторов	Показать уровень нарушений обслуживания, выявленного ИТ-подразделением	Владелец процесса, руководство ИТ-отдела, владелец процесса SLA, бизнес-клиент, члены команды, владелец процесса SIP.
Средние трудозатраты для выполнения услуги командой подрядчиков	Общее число часов/трудовых дней, необходимое для оказания услуги.	Оценить эффективный временной показатель для выполнения одной услуги.	Владелец процесса, руководство ИТ-отдела, владелец процесса SLA, бизнес-клиент, члены команды, владелец процесса SIP.
Степень удовлетворенности заказчиков	Показывает реальное отношение общее количество выполненных услуг на количество услуг, получивших приемку от компании заказчика	Повышать качество выполненных услуг подрядной организацией	Владелец процесса, руководство ИТ-отдела, владелец процесса SLA, бизнес-клиент, члены команды, владелец процесса SIP.

Документирование процесса

SLA или соглашение об уровне предоставления услуг (англ. Service Level Agreement (SLA)) - формальный договор между заказчиком (заказчик и потребитель) услуги и её поставщиком, содержащий описание услуги, права и обязанности сторон и, самое главное, согласованный уровень качества предоставления данной услуги. В таком соглашении может содержаться детальное описание предоставляемого сервиса, в том числе перечень параметров качества, методов и средств их контроля, времени отклика поставщика на запрос от потребителя, а также штрафные санкции за нарушение этого соглашения.

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

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

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

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

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

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

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

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

Функции CRM

Современные CRM решения должны обладать следующими функциями:

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

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

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

- управление временем (тайм менеджмент) - настройка, создание, корректировка расписаний, планирование бюджета времени и т.д.;

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

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

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

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

Окружение процесса

a) Управление отчетностью

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

b) Управление Конфигурациями

Процесс управления конфигурациями занимается регистрацией всех доступных версий программно-аппаратного обеспечения CRM систем в базе данных управления конфигурациями (CMDB). Программное обеспечение CRM, поставляемое в библиотеку DSL, а также аппаратное обеспечение для DHS обязательно проходит процедуру регистрации в базе данных управления конфигурациями с согласованием обеспечиваемого уровня детализации.

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

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

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

Метрика	Описание	Задача метрики	Аудитория
Степень удовлетворенности клиентов	Метрика оценивает качество предоставляемых услуг	Повысить качество предоставляемых услуг	Владелец процесса, руководство ИТ-отдела, владелец процесса SLA, бизнес-клиент, члены команды, владелец процесса SIP.
Число инцидентов	Общее число инцидентов является показателем уровня нарушений обслуживания, выявленного ИТ-подразделением	Улучшить показатель неустойчивости обслуживания	Владелец процесса, руководство ИТ-отдела, владелец процесса SLA, бизнес-клиент, члены команды, владелец процесса SIP.
Средние трудозатраты для планового обучения клиентов	Общее число часов/трудовых дней, необходимое для обучения клиентов	Оценить эффективный временной показатель для планового обучения	Владелец процесса, руководство ИТ-отдела, владелец процесса SLA, бизнес-клиент, члены команды, владелец процесса SIP.
Степень эффективности от внедренной CRM	Метрика показывает эффективность, прибыль компании, профит от новой CRM системы	Подсчитывать эффективность от действий, предпринимаемых компанией для улучшения обслуживания клиентов	Владелец процесса, руководство ИТ-отдела, владелец процесса SLA, бизнес-клиент, члены команды, владелец процесса SIP.
Количество привлеченных клиентов за 1 месяц	Метрика показывает эффективность работы CRM системы	Подсчитывать количество клиентов, которые стали пользоваться услугами компании. 30 календарных дней - срок отсчета	Владелец процесса, руководство ИТ-отдела, владелец процесса SLA, бизнес-клиент, члены команды, владелец процесса SIP.
Общее число продаж	Суммарное количество оборота услуг/товаров за месяц	Оценивать прирост или уменьшение продаж	Владелец процесса, руководство ИТ-отдела, владелец процесса SLA, бизнес-клиент, члены команды, владелец процесса SIP.
Увеличение числа повторных продаж для одного клиента	Метрика показывает степень удержания клиентов	Подсчитывать количество повторных покупок одним клиентом	Владелец процесса, руководство ИТ-отдела, владелец процесса SLA, бизнес-клиент, члены команды, владелец процесса SIP.
Время от контакта до заключения сделки	Метрика позволяет оценить время средней совершенной сделки	Увеличить скорость процессов в компании	Владелец процесса, руководство ИТ-отдела, владелец процесса SLA, бизнес-клиент, члены команды, владелец процесса SIP.
Число отказов от совершения покупки	Общее число клиентов, которые по тем или иным причинам отказались от сделки	Уменьшить число незавершенных сделок	Владелец процесса, руководство ИТ-отдела, владелец процесса SLA, бизнес-клиент, члены команды, владелец процесса SIP.

Документирование процесса

- Руководство по установке - документ для администратора системы, который в пошаговой форме содержит рекомендации для корректной и полной установки схемы CRM в систему, а также настройку доступов.

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

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

- Организация электронной рассылки -- инструкция по отправке массовой рассылки из CRM системы.

- Обработка инцидентов -- инструкция по регистрации инцидентов, поиску решений и переписке по инцидентам.

Заключение по второй главе

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

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

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

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

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