Дипломная (вкр): Обзор решений моделирования бизнес-процессов управления ИT сервисами
После мониторинга услуг нужно составить отчеты об уровне сервисов и предоставить их заказчику и другим процессам. Данные отчеты следует проанализировать для определения возможных направлений улучшения и инициации процессов по улучшениям. Результатом анализа может стать пересмотр соглашения об уровне услуг.
На рисунке 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).