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

3. Моделирование бизнес процессов

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

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

Рисунок 3.1 - Диаграмма процесса управления мощностями

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

На рисунке 3.2 показана схема управления мощностями.

Рисунок 3.2 - Схема процесса управления мощностями

Задачей процесса управления мощностями бизнеса является определение текущих и будущих потребностей заказчика. Данное планирование выполняется исходя из стратегий и планов бизнеса. Схема процесса показана на рисунке 3.3.

Рисунок 3.3 - Схема управления мощностями бизнеса

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

Рисунок 3.4 - Схема управления мощностями сервиса

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

Рисунок 3.5 - Схема управления мощностями ресурсов

Каталогизация рисков и их предотвращение

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

3.2 Моделирование процессов управление уровнем услуг

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

Рисунок 3.6 - Диаграмма процесса управления уровнем услуг

Данный процесс состоит из этапов:

· Обсуждение и согласование требований;

· Оформление соглашения об уровне услуг;

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

· Отчетность и анализ уровня сервисов.

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

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

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

· От управления мощностями требуется информация об имеющихся мощностях.

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

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

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

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

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

· От процессов разрешения требуется информация об инцидентах и проблемах для их разрешения.

· От процессов управления взаимоотношениями с бизнесом нужны требования, стратегии и планы бизнеса.

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

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

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

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

На рисунке 3.7 показана схема этапов процесса управления уровнем услуг.

Рисунок 3.7 - Схема этапов управления уровнем услуг

Следует более подробно рассмотреть этапы обсуждения и согласования требований и оформления соглашения об уровне услуг.

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

Рисунок 3.8 - Схема этапа определения и согласования требований процесса управления уровнем услуг

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

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

Рисунок 3.9 - Схема этапа формирования соглашения об уровне услуг процесса управления уровнем услуг

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

Каталогизация рисков и меры их предотвращения

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

3.3 Моделирование процесса управления непрерывностью и доступностью услуг

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

Рисунок 3.10 - Диаграмма процесса управления непрерывностью и доступностью услуг

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

Рисунок 3.11 - Схема процесса управления непрерывности и доступности

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

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

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

Следует более подробно рассмотреть этапы определения требований к стратегии непрерывности и доступности и внедрения изменений. На рисунке 3.12 показана схема этапа определения требований к стратегии.

Рисунок 3.12 - Схема этапа определения требований к стратегии непрерывности и доступности

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

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

После данного этапа происходит внедрение изменений. На рисунке 3.13 показана схема этапа.

Рисунок 3.13 - Схема этапа внесения изменений процесса управления непрерывностью и доступностью

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

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

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

Каталогизация рисков и их решение

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

3.4 Моделирование процессов обеспечения информационной безопасности

Управлением информационной безопасностью является: федеральный закон, конституция, указы, ГОСТ 15408, устав компании, ГОСТ 18044, а механизмом являются: системы мониторинга, системы криптозащиты, анализаторы протоколов, системы аутентификации, видеонаблюдение, средства контроля доступом (рис. 3.14).

Рисунок 3.14 - Диаграмма процесса управления информационной безопасностью

Диаграмма активности

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

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

Рисунок 3.15 - Диаграмма активности

Каталогизация рисков и их предотвращение

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

3.5 Моделирование процесса бюджетирования и учета затрат

Основные и вспомогательные бизнес-процессы

Рисунок 3.16 - Function tree ARIS дерево основных функций

· Закупка:

- закупка необходимого оборудования;

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

• Хранение и поддержка:

- Поддержка бесперебойной работы программ, систем, облачного хранилища данных;

- Аренда помещения:

• Риски;

• Обучение:

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

• Оплата труда:

- Заработная плата специалистам;

- Заработная плата дополнительным сотрудникам для производства дополнительных работ (помощники, бухгалтера и пр.);

• Внешние заказные работы:

- ремонт оборудования;

- установка лицензионных программ;

- ведение бухгалтерского учета затрат на проект;

- настройка сети, беспроводного интернета и пр.;

• Оформление отчетов по планированию бюджета по проекту.

Жирным выделены основные процессы, обычным шрифтом соответственно - вспомогательные (рис. 3.16).

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

Рисунок 3.17 - Контекстная диаграмма планирование и учет затрат на ИТ

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

Рисунок 3.18 - Диаграмма декомпозиции закупки оборудования

Укрупненные модели основных бизнес-процессов бюджетирования (см. рис. 3.19):

Рисунок 3.19 - Контекстная диаграмма укрупненной модели

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

Рисунок 3.20 - Диаграмма декомпозиции. Закупка оборудования

Рисунок 3.21 - Контекстная диаграмма Хранение товара на складе

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

Рисунок 3.22 - Поступление и хранение оборудования на складе

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

Рисунок 3.23 - Диаграмма использования. Оплата труда за выполненный проект

Зарплата рассчитывается под «управлением» ТК РФ и устава компании по данным из трудового договора и по табелю о рабочих днях, которые являются «входами». Заработные платы рассчитывает бухгалтер. В результате получается оплата труда работникам и табель о зарплате (рис. 3.24).

Рисунок 3.24 - Контекстная диаграмма оплата труда за выполненный проект

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

Рисунок 3.25 - Диаграмма декомпозиции оплата труда за выполненный проект

Каталогизация рисков и их предотвращение

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

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

Если изобразить на диаграмме процесс управления изменениями на самом верхнем уровне в нотации IDEF0, то он будет выглядеть, как показано на рисунке 3.26.

Рисунок 3.26 - Контентная диаграмма процесса управления изменениями

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

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

- Проведение срочных изменений;

- Прием и регистрация, первичная проверка и классификация запросов на изменение;

- Планирование и согласование изменений;

- Утверждение планов внесения изменений;

- Мониторинг и координация внесения изменений;

- Оценка проведенных изменений;

- Отчетность по изменениям.

Диаграмма 2-го уровня декомпозиции процесса управление изменениями изображена на рисунке 3.27.

Рисунок 3.27 - Диаграмма 2-го уровня декомпозиции управления изменениями

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

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

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

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

Каталогизация рисков и их предотвращение

Риски	Меры по предотвращению
Риск появления ошибочных RFC	- Внедрение работ по тестированию и инспекции RFC
Риск возникновения неактуальных RFC	- Удаление из базы CMDB данных о неиспользуемых
Риск возникновения негативного влияния от изменения	- Тщательное планирование изменений - Планирование возможности отката изменений
Риск увеличения большого количества неисполненных изменений	-Увеличить контроль за соблюдением исполнения изменений

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

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

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

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

Если изобразить на диаграмме процесс управления инцидентами на самом верхнем уровне в нотации IDEF0, то он будет выглядеть, как показано на рисунке 3.28.

Рисунок 3.28 - Диаграмма процесса управления инцидентами

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

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

Рисунок 3.29 - Схема последовательности выполнения процесса управления инцидентами

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

Рисунок 3.30 - Диаграмма взаимодействия процесса управления инцидентами

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

1. Разработки и управления планом действий по решению вопроса;

2. Инициации конкретных назначений заданий для персонала и бизнес-партнеров;

3. Эскалации инцидента, если требуется, когда цель не достигается вовремя;

4. Обеспечения внутреннего взаимодействия в соответствии с целями обслуживания;

5. Защиты интересов вовлеченных бизнес-партнеров.

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

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

2. Разработки специфических для подразделений отчетов и процедур;

3. Поддержки и совершенствования взаимодействия и списков эскалации;

4. Участие в процессе анализа проблем.

Рисунок 3.31 - Диаграмма взаимодействия трех уровней технической поддержки

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

§ идентифицирует недостающие звенья процесса;

§ идентифицирует нарушения исполнения соглашений об уровне услуг (SLA);

§ отслеживает ход выполнения процесса предоставления услуг и решение вопроса с инцидентами;

§ определяет тенденции развития процесса управления инцидентами для его совершенствования.

Каталогизация рисков и их предотвращение

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

3.8 Моделирование процесса управления проблемами

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

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

Рисунок 3.32 - Диаграмма процесса управления проблемами

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



Рисунок 3.33 - Схема последовательности выполнения процесса управления проблемами

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

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

Рисунок 3.34 - Диаграмма взаимодействия процесса управления проблемами с окружающим процессами

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

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



Рисунок 3.35 - Диаграмма процесса поиска решения проблемы

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

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

Рисунок 3.36 - Схема процесса контроля ошибок

Ответственный за выполнение процесса управления проблемами отвечает за такие аспекты, как:

· Разработка и поддержание высокого уровня контроля проблем и ошибок,

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

· Сбор, хранение и документирование актуальной информации,

· Совершенствование процессов контроля ошибок и проблем,

· Анализ ключевых показателей,

· Повышение реактивности на оказание качественных услуг.

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

o Выявлять и регистрировать проблемы путем их анализа на основании информации об инцидентах,

o Изучать проблемы и ошибки с учетом их приоритетности,

o Обеспечивать процесс подачи заявления на изменения,

o Выполнять мониторинг ИТ-инфраструктуры ошибки и проблемы,

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

o Следить за тенденциями и принимать действия для их устранения,

o Пресекать распространение проблем на всю ИТ-инфраструктуру.

Каталогизация рисков и их предотвращение

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

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

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

Рисунок 3.37 - Диаграмма последовательности. Оформление отчетов

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

Рисунок 3.38 - Контекстная диаграмма управление отчетностью по услугам

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

Рисунок 3.39 - Диаграмма декомпозиции управление отчетностью по услугам

Каталогизация рисков и их предотвращение

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

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

Если изобразить на диаграмме процесс управления релизами на самом верхнем уровне в нотации IDEF0, то он будет выглядеть, как показано на рисунке 3.40.

Рисунок 3.40 - Диаграмма верхнего уровня процесса управление релизами

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

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

Ш Выработка политики в отношении релизов и планирование. Ответственным за процесс является менеджер проекта;

Ш Проектирование и разработка. Ответственный - разработчики;

Ш Компоновка и конфигурирование релизов. Ответственный - релиз менеджер;

Ш Тестирование и приемка релиза. Ответственный - тестировщик, инженеры по качеству продуктов;

Ш Планирование и развертывание. Ответственный - релиз менеджер;

Ш Подготовка, обучение и оповещение. Ответственный - менеджер проекта;

Ш Распространения релизов и инсталляция. Ответственный - системный администратор.

Диаграмма 2-го уровня декомпозиции процесса управление релизами изображена на рисунке 3.41.

Рисунок 3.41 - Декомпозиция процесса управления релизами

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

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

- Информация о дефектах. Данные поступают в совокупности от процессов PRB (Процесс управления проблемами), SEC (Процесс управления безопасностью), INC (Процесс управления безопасностью).

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

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

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

· Нагрузка персонала (количество человеко-часов и общего времени на сборку и тестирование отдельных изменений).

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

· Возможные сложности интеграции между новыми программно-аппаратными компонентами и имеющей ИT-инфраструктурой предприятия.

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

На этапе бизнес процесса выработки политики в отношении релизов и их планирование рассматриваются следующие вопросы:

• Составление графика ввода в коммерческую эксплуатацию релиза;

• Составление плана-графика тестирования;

• Согласование территориальных объектов, тестовых и продуктивных сред, используемых мощностей, на которых произойдет распространение релиза;

• Составление плана-оповещений сотрудников и бизнес-пользователей;

• Согласование ролей на проекте и распределение ответственностей;

• Разработка конкретных планов для отката установки;

• Разработка стратегии обеспечения качества релиза;

• Планирование приемки релиза командой тестирования, руководством и бизнес-пользователями.

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

Проектирование и разработка

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

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

Компоновка и конфигурирование релиза

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

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

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

Тестирование и приемка релиза

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

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

Результатом деятельности на этапе тестирования и приемки релиза будет являться:

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