Файл: Вадим Алджанов итархитектура от а до Я Теоретические основы. Первое.pdf

Время перехода в каталог сервисов
Время перехода из каталога сервисов
Своевременность и полнота информации
Несвоевременная регистрация
Отношение сервисов каталога к сервисам портфеля
Управление деятельностью ИТ департамента (IT Governance DG)
Процесс управление деятельностью ИТ департамента является вспомогательным процессом в функционировании ИТ. В контексте управления ИТ сервисами рассматривается не как стандарты по Управлению ИТ, а вспомогательный процесс, регулирующий деятельность по принятию решений, организацию работы с руководящими документами ИТ и т п. Управление
ИТ отвечает на такие вопросы как:
Регламентирование административных мероприятий по управлению ИТ
Организация работы с ИТ документацией по управлению ИТ сервисами
Деятельность по процессу:
Разработка и утверждение процессов управления и взаимодействия ИТ
Разработка и утверждение руководящих ИТ документов
Разрешение конфликта интересов
Входы процесса:
Требования бизнеса
Рекомендации мировых практик в области управления ИТ, Управления Проектами, Аудита,
Корпоративного Управления
Выходы процесса:
Протокол решений ИТ комитета и Руководящие ИТ документы
Участники процесса:
ИТ Комитет
Ключевые моменты процесса:
Комитет ИТ собирается не реже чем один раз в квартал
Владельцем процесса является ИТ департамент. При высоком уровне зрелости организации, владельцем процесса может быть административный департамент, в рамках корпоративного управления организацией в целом.
ИТ департамент обеспечивает управление процессов, если имеется соответствующие ИТ компоненты
Назначение процесса (WHAT) и цели процесса (WHY):
Организация процесса управления ИТ формирования стратегического ИТ бюджета
Организация деятельности ИТ формирования оперативного ИТ бюджета
Процедуры (HOW), Зона применения (WHEN) и Зона ответственности (WHO):
Формирование руководящих документов ИТ
Обсуждение руководящих документов ИТ
Принятие руководящих документов ИТ
Регистрация решения ИТ комитета
Сбор подписей по решения ИТ комитета
Регистрация документов в отделе документооборота
Ознакомление с руководящими документами ИТ
Контроль за исполнением руководящих документов ИТ
Внесение изменений в руководящие документы ИТ
Разрешение конфликтов интересов

Критерии результативности – (KGI)
Удовлетворённость владельцев бизнеса
Критерии эффективности – (KPI)
Количество утвержденных руководящих ИТ документов
Количество внесенных изменений в руководящие ИТ документы
Количество и сроки проведения ИТ комитетов
Нарушения по количеству или срокам проведения ИТ комитетов
ЭТАП ДИЗАЙНА (Design Stage)
Введение
Этап Дизайна является не менее важным и наиболее объемным этапом управления ИТ сервисами. На данном этапе производится планирование сервиса, детализация всех аспектов функционирования сервиса, закладывается основа плана внедрения и сопровождения сервиса.
По сути происходит основная «мозговая» деятельность. Для Управления Проектами соответствует фазе планирования проекта.
Цели и задачи:
Проектирование новых и изменение имеющихся сервисов для организации
Сервис дизайн вовлекается только для «важных» стратегических изменений в ИТ архитектуре.
Формирование дизайна и планирование сервиса и процессов.
Данный этап определяется следующими процессами (7):
Координация дизайна и планирования (Design Coordination) *
Управление рисками (Risk Management) *
Управление архитектурой (Architecture Management) *
Управление соответствия требованиям (Compliance Management) *
Управление Каталогом Сервисов (Service Catalogue Management)
Управление Уровнем Услуг (Service Level Management)
Управление доступностью (Availability Management)
Управление мощностями (Capacity Management)
Управление непрерывностью сервисов (It service Continuity Management)
Управление Информационной Безопасностью (Information Security Management)
Управление поставщиками (Supplier Management)
Деятельность процессов дизайна концентрирует свое внимание на двух ключевых аспектах:
Ресурсы (Resources) – прямые активы которые можно измерить
Возможности (Capability) – способности организации координировать, контролировать и распределять ресурсы для создания ценности.
Помимо этого, вводятся два важных атрибута сервиса:
Возможности сервиса (Utility), что он делает. Соответствие функциональным требованиям
«fit to purpose».
Качество сервиса (Warranty) – насколько хорошо он это делает, «fit for use».
Этап Дизайна сервисов оперирует четырьмя основными понятиями:
Люди (People)
Продукты (Products)
Процессы (Processes)
Партнеры (Partners)

Основные измерения этапа Дизайна сервисов:
Функциональность (возможности сервиса)
Ресурсы (люди, финансы, технологии)
Время
Баланс этих трех показателей позволяет достичь максимальной эффективности этапа планирования сервиса – Качества сервиса.
При разработке программного обеспечения можно использовать следующие механизмы:
Структурированная Система Разработки (Structured System Development)
Традиционная линейная (Traditional Linear)
«Водопад» (Waterfall)
«V-Модель» (V-Model)
Быстрая Разработка (Rapid Application Development) – Быстрая разработка за счет повторного использования готовых и разработанных компонентов.
Коробочные Коммерческие Решения (Commercial Off-the-shell Solutions COTS)
Использование и адаптация коммерческих продуктов (COTS)
Выделяется пять ключевых аспектов Проектирования услуг

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

Хотя существует возможность, что для разработанного решения не потребуется участие третьих сторон (то есть поставщиков), тем не менее, на практике чаще всего они участвуют, а, следовательно, необходимо выполнить следующее: завершение всех необходимых проверок выбранного поставщика; заключение контрактов с поставщиком; снабжение выбранного решения.
Разработка решения. Сюда относится деятельность по трансляции проекта услуги в план по ее разработке. Каждый план будет ответственен за разработку одного или более компонентов услуги и должен включать следующее: потребности бизнеса; стратегия, применяемая для разработки и/или приобретения решения; временные рамки; требуемые ресурсы, в том числе возможности и инфраструктуры IT, квалифицированный персонал и т. п.; разработка услуги и ее компонентов, в том числе механизмов управления, формирования отчетности, измерения и т. п. план тестирования услуги и ее компонентов.

На выходе Сервис Дизайна формируется Пакет Сервис Дизайна (Service Design Package SDP), который включает в себя:
Процессы данного этапа формируют три основных документа: Пакет Дизайна Сервиса,
Пакет Дизайна Уровня предоставления услуг
Детальную Архитектуру Предприятия.

На выходе, возможна корректировка стратегических планов и бюджетов. Пакеты решений передаются далее на этап Внедрения. В плане Управления Проектами принимается окончательное решение по началу проекта и выделение ресурсов, определения сроков ИТ проекта.
Координирование процесса Дизайна сервиса (Design
Coordination DC)
Процесс Координирования Дизайна сервиса является главным на этапе Дизайна». Фактически процесс является аналогом процесса «Управления Изменениями» и отвечает на такие вопросы как:
Формирование процесса дизайна сервиса.
Координация деятельности различных процессов управления ИТ сервисами
Интеграция фаз и процессов Управления Проектами
Деятельность по процессу:
Утверждение процесса дизайна сервисов
Координация деятельности по проектированию ИТ сервисов
Входы процесса:
Выходы процессов Стратегического этапа
Фаза инициализации Управление Проектами
Выходы процесса:
Детальная ИТ Архитектура Предприятия
Пакет Дизайна Сервиса
Пакет Дизайна Предоставления Услуг
Протокол решения ИТ комитета
Необходимые данные для фазы планирования Управления Проектами
Участники процесса:

ИТ комитет
ИТ архитектор
Руководитель ИТ Проектов
Менеджер ИТ проектов
Экспертная группа, в составе которой эксперты и инженеры ИТ, представители бизнеса
Ключевые моменты процесса:
ИТ департамент является владельцем процесса
Назначение процесса (WHAT) и цели процесса (WHY):
Организация процесса дизайна сервиса
Организация дизайна сервиса
Процедуры (HOW), Зона применения (WHEN) и Зона ответственности (WHO):
Координация процессов дизайна ИТ сервисов
Координация требований Управления Проектами
Подготовка Пакетов Дизайна Сервиса и Предоставления Услуг
Утверждение Пакетов Дизайна Сервиса и Предоставления Услуг
Утверждение ИТ Архитектуры Предприятия
Критерии результативности – (KGI)
Критерии эффективности – (KPI)
% требований спецификаций Сервис Дизайна предоставленных в срок и в соответствии с бюджетом
% Планов Сервис Дизайна предоставленных в срок и в соответствии с бюджетом
% Пакетов Сервис Дизайна законченных в срок
% соответствия бизнес требований и решений, сформированных в Пакетов Сервис Дизайна
% точности при оценке стоимости сервиса или проекта на этапе Сервис Дизайна

Решение Комитета по Управлению Рисками
Рекомендации по Информационной Безопасности
Входы процесса:
Процесс Управление Отношениями с Бизнесом
Процесс Управления Требованиями
ИТ архитектура
Contract Risks
Service Provider Risks
Design Risks
Transition Risks
Operational Risks
Market Risks
Выходы процесса:
Подписанный протокол решения ИТ комитета
Подписанный протокол решения Комитета по управлению Рисками
Risks responses
Участники процесса:
ИТ комитет
Комитет по управлению рисками
ИТ директор
ИТ архитектор
Руководители ИТ подразделений
Экспертная группа
Представители бизнеса
Представители комитета управления рисками
Представители департамента Безопасности
Ключевые моменты процесса:
Департамент Внутреннего ИТ Аудита (Комитет по Управлению Рисками) является владельцем процесса
Департамент ИТ является исполнителем (управляющим) по вопросам связанных с информационными технологиями.
Департамент Информационной Безопасности является консультантом в процессе
Назначение процесса (WHAT) и цели процесса (WHY):
Организация процесса управления рисками
Организация управления рисками
Процедуры (HOW), Зона применения (WHEN) и Зона ответственности (WHO):
Организация процесса управления рисками
Согласование процесса управления рисками
Утверждение процесса управления рисками
Внесение изменений в процесс управления рисками
Проведение деятельности по обнаружению рисков
Проведение деятельности по анализу рисков
Формирование реестра рисков
Проведение деятельности по оценке рисков
Выработка мер противодействия рискам
Оценка мер противодействия рискам
Разрешение конфликта интересов по управления рисками
Критерии результативности – (KGI)