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

Рисунок 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 должны произойти обновления требований для процесса управления уровнями сервиса и для процесса управления релизами.

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

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

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.       Инициации конкретных назначений заданий для персонала и бизнес-партнеров;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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