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

Рисунок 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 должна обновиться.

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

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

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

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

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

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

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

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

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

Планирование и развертывание

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

Процесс планирование и внедрения включает в себя:

-       планирование графиков установки релизов;

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

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

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

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

•        Одновременная полная установка/развертывание релиза;

•        Медленное поэтапное развертывание/установка релиза, которое делится на следующие виды:

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

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