1 задание. Вадим Алджанов итархитектура от а до Я Теоретические основы. Первое
 Скачать 8 Mb.
|
|
Управление Рисками (Risk Management RM) Управление Рисками процесс этапа «Дизайна». Является ключевым процессом для организации. Данный процесс отвечает на такие вопросы как: Формирование процесса управления рисками в рамках организации. Формирование и утверждение реестра рисков Расчет стоимости рисков Анализ рисков и механизмов противодействия или снижения рисков Формирование и утверждение реакции на риски Порядок взаимодействия ИТ департамента с бизнесом по вопросам управления рисками Порядок взаимодействия подразделений внутри ИТ департамента по вопросам управления рисками Деятельность по процессу: Формирование и утверждение процесса управления рисками Формирование и утверждение реестра рисков Формирование и утверждение реакции на риски Выявление рисков Определение владельцев рисков Оценка рисков Формирование реакции на риски Внедрение реакции на риски Gain assurances of effectiveness and efficiency Embed and Review Разработка и согласование процесса управления рисками Исполнение требований комитета по управлению рисками Определение рисков на всех этапах жизненного цикла сервиса Решение Комитета по Управлению Рисками Рекомендации по Информационной Безопасности Входы процесса: Процесс Управление Отношениями с Бизнесом Процесс Управления Требованиями ИТ архитектура Contract Risks Service Provider Risks Design Risks Transition Risks Operational Risks Market Risks Выходы процесса: Подписанный протокол решения ИТ комитета Подписанный протокол решения Комитета по управлению Рисками Risks responses Участники процесса: ИТ комитет Комитет по управлению рисками ИТ директор ИТ архитектор Руководители ИТ подразделений Экспертная группа Представители бизнеса Представители комитета управления рисками Представители департамента Безопасности Ключевые моменты процесса: Департамент Внутреннего ИТ Аудита (Комитет по Управлению Рисками) является владельцем процесса Департамент ИТ является исполнителем (управляющим) по вопросам связанных с информационными технологиями. Департамент Информационной Безопасности является консультантом в процессе Назначение процесса (WHAT) и цели процесса (WHY): Организация процесса управления рисками Организация управления рисками Процедуры (HOW), Зона применения (WHEN) и Зона ответственности (WHO): Организация процесса управления рисками Согласование процесса управления рисками Утверждение процесса управления рисками Внесение изменений в процесс управления рисками Проведение деятельности по обнаружению рисков Проведение деятельности по анализу рисков Формирование реестра рисков Проведение деятельности по оценке рисков Выработка мер противодействия рискам Оценка мер противодействия рискам Разрешение конфликта интересов по управления рисками Критерии результативности – (KGI) Критерии эффективности – (KPI) •Количество рисков •Количество критических рисков •Количество рисков по категориям Управление ИТ Архитектурой (Architecture Management AM) Управление ИТ архитектурой процесс этапа «дизайна». Является ключевым процессом для организации и ИТ департамента в частности. Данный процесс отвечает на такие вопросы как: •Организация процесса Управления Архитектурой •Разработка ИТ Архитектуры Предприятия •Разработка Архитектуры ИТ сервисов Архитектура предприятия должна включать в себя следующие основные архитектуры: Архитектура услуг – транслирует приложения, инфраструктуры, организацию и поддержку деятельностей в набор услуг. Архитектура услуг предоставляет независимый, интегрированный в бизнес подход для предоставления услуг бизнесу. Она предлагает модель для разделения между Архитектурой услуг, Архитектурой приложений, Архитектурой инфраструктуры и Архитектуры данных. В рамках Архитектуры услуг также рассматриваются вопросы обеспечения стойкости к сбоям, дальнейшей корректировки и обеспечения безопасности. Архитектура приложений – предлагает детальный план по развитию и доставке индивидуальных приложений, отображает функциональные требования бизнеса к приложениям и показывает взаимозависимости между приложениями. Использование подхода, основанного на компонентах, максимизирует повторное использование и помогает приложениям быть гибкими в условиях изменяющихся политик снабжения. Архитектура данных/информации – описывает логические и физические информационные активы организации, и ресурсы управления ими. Она показывает, как распределены информационные ресурсы и управление ими для достижения корпоративной цели. Архитектура инфраструктуры – описывает структуру, функциональность и географическое распределение программного и аппаратного обеспечения, компонентов коммуникации, а также относящиеся к ним стандарты. Архитектура окружения – описывает аспекты, уровни и типы контроля окружения, а также их управления. Деятельность по процессу: •Организация процесса управления Архитектурой Входы процесса: •Входы процессов стратегического этапа Выходы процесса: •ИТ Архитектура Предприятия •Архитектура ИТ сервиса Участники процесса: •ИТ комитет •ИТ архитектор •Главы подразделений ИТ департамента •Экспертная группа Ключевые моменты процесса: •ИТ департамент является владельцем процесса Критерии результативности – (KGI) Критерии эффективности – (KPI) Управление Соответствиями Требованиям (Compliance Management COM) Управление Соответствия Требованиям процесс этапа «дизайна». Процесс должен отвечает на такие вопросы как: •Соответствие ИТ Архитектуры требованиям ИТ Стратегии •Соответствие ИТ Архитектуры требованиям регуляторов •Соответствие ИТ Архитектуры рекомендациям международных стандартов и практик Деятельность по процессу: •Назначение процесса (WHAT) и цели процесса (WHY): •Организация процесса управления соответствия требованиям •Сбор требований контролирующих органов •Сбор рекомендаций международных стандартов и практик •Анализ требований •Разрешение конфликта интересов по соответствию требованиям Входы процесса: •Выходы процессов стратегического этапа •Требования контролирующих органов •Рекомендации международных стандартов и практик Выходы процесса: •Протокол решения ИТ комитета Участники процесса: •ИТ комитет •ИТ архитектор •Главы подразделений ИТ департамента •Экспертная группа Ключевые моменты процесса: •ИТ департамент является владельцем процесса Критерии результативности – (KGI) Критерии эффективности – (KPI) Управление Каталогом Сервисов (Service Catalog Management SCM) Управление Каталогом Сервисов процесс этапа «Дизайна» и является частью процесса «Управления Портфелем Сервисов». В каталог сервисов находятся «рабочие» сервисы, т. е. сервисы которые находятся в эксплуатации и доступны для пользователей. Цели процесса: •Перечень сервисов, предоставляемых ИТ департаментом, находящиеся на этапе сопровождения. •Управление информацией, содержащейся в каталоге услуг Задачи процесса: •Формирование каталога услуг, находящихся в эксплуатации •Управление состояние каталога услуг, •Организация взаимодействия с портфелем сервисов Действия, которые должны быть предприняты в рамках Управления Каталогом услуг: •Утверждение и документирование всех услуг вместе с компонентами, относящимися к ним; •Взаимодействие с Управлением Портфелем услуг с целью согласования информации, содержащейся в Портфеле услуг и Каталоге услуг; •Формирование и поддержка Каталога услуг с привязкой к Портфелю услуг; •Взаимодействие с IT и бизнесом с целью установления зависимостей между бизнес-единицами с их бизнес-процессами и поддерживающими услугами. •Взаимодействие со службами поддержки, поставщиками и Управлением конфигурациями с целью установления зависимостей между услугами и поддерживающими компонентами, содержащимися в Техническом Каталоге услуг. Различают два виды сервисов: Бизнес Сервис Каталог (Business Service Catalogue) – ИТ сервисы видимы и предоставляемые пользователям и клиентам Технический Сервис Каталог (Technical Service Catalogue) – ИТ сервисы, обычно не видимые пользователям и клиентам Основными входами процесса являются: •стратегии и планы бизнеса и IT, текущие и будущие требования к Портфелю услуг; •влияние, приоритеты и риски, связанные с каждой услугой или с изменением требований к ней. Эту информацию предоставляет процесс Анализа влияния на бизнес; •требования бизнеса – детальное описание новых или измененных требований бизнеса к Портфелю услуг; •Портфель услуг; •Система управления конфигурациями (CMS); обратная связь с другими процессами в рамках жизненного цикла услуги. •Процесс управления Портфелем Сервисов •Процесс управления Взаимодействия с Бизнесом •Процесс управления Портфелем Сервисов •Процесс управления Взаимодействия с Бизнесом Выходами процесса Управления Каталогом услуг являются: •утвержденная руководством документация, описывающая услуги; •обновления Портфеля услуг, в результате которых в нем будет содержаться актуальная информация о статусах и зависимостях услуг; •Каталог услуг, который содержит детальное описание текущих статусов услуг, вместе с описанием интерфейсов и зависимостей. •Подписанный протокол решения ИТ комитета Участники процесса: •ИТ комитет •Менеджер по управлению портфелем сервисов Ключевой показатели процесса: •Процентное соотношение количества услуг, которые содержатся в Каталоге услуг, к количеству услуг, которые предоставляются заказчикам в определенный момент времени. •Количество расхождений между информацией, содержащейся в Каталоге услуг, и «реальной ситуацией». Ключевые моменты процесса: •ИТ департамент является владельцем процессом. •Каталог услуг для бизнеса связывает услуги и бизнес-процессы, то есть то, что волнует бизнес, •Технический Каталог услуг связывает услуги с тем, что обеспечивает их работу, то есть то, что волнует IT. Основными рисками для Управления Каталогом услуг является неточная информация, поступающая от бизнеса и IT, а также плохо организованный доступ к Каталогу услуг. Критерии результативности – (KGI) Критерии эффективности – (KPI) •Количество сервисов в каталоге •Среднее время перехода сервиса из портфеля в каталог •Среднее время нахождения сервиса в каталоге> 3 лет •Отношение технических и бизнес сервисов> 70% •Уровень полноты документирования сервиса> 70% Управление Уровнем Предоставления Сервисов (Service Level Management SLM) Управление Уровнем Сервисов процесс этапа «Дизайна». Является частью «Управления Портфелем Сервисов». Управление уровнем услуг – процесс, ответственный за обсуждение Соглашений об уровне услуг, и гарантирующий их выполнение. Он ответственен за то, что процессы Управления услугами, соглашения операционного уровня и внешние договоры будут соответствовать согласованным целевым показателям уровня услуги. SLM является своего рода точкой взаимодействия поставщика услуг и заказчика. Цели процесса: •Организация процесса предоставления сервисов •Согласование уровня предоставляемых сервисов. •Обеспечение и улучшение взаимоотношений заказчиков и поставщиков; •Обеспечение того, что целевые значения для услуг достижимы и их можно измерить; •Мониторинг и улучшение удовлетворенности заказчиков уровнем предоставляемых услуг; •Гарантия того, что заказчики имеют четкое и недвусмысленное ожидание уровня услуги; Задачи процесса: •развитие взаимоотношений с бизнесом; •переговоры и согласование требований и целевых показателей, а также документирование и управление SLA для всех услуг, находящихся в промышленной эксплуатации. •развитие и управление OLA, чтобы обеспечить соответствие и корреляцию с SLA. •предупреждение отказов, уменьшение рисков, улучшение качества услуг; •управление и отчетность по всем услугам, обзор всех слабостей и «брешей» SLA; •координация Плана совершенствования услуг. План совершенствования услуг (Service Improvement plan) – формальный План для внедрения улучшений в процесс или услугу. Основная деятельность в рамках процесса должна включать следующее: •документирование, согласование, утверждение требований заказчиков в форме SLR и управление ими в рамках жизненного цикла услуги с помощью SLA; •мониторинг и измерение производительности услуг в рамках SLA; •измерение и мониторинг пользовательской удовлетворенности; •формирование отчетности; •сбор и анализ информации, полученной из отчетов; инициирование улучшений в рамках Плана совершенствования услуг; •регистрация всех положительных и отрицательных отзывов; •Формирование и утверждение процесса управления Уровнем Сервисов Входами для процесса являются: •информация от бизнеса – стратегии, планы, текущие и будущие требования; •Анализ влияния на бизнес – информация о влиянии, приоритетах, рисках и количестве пользователей по каждой услуге; •Портфель услуг и Каталог услуг; •информация об изменениях – информация от процесса Управления изменениями; •обратная связь с заказчиками, положительные и отрицательные отзывы. Выходами процесса являются: •отчеты об услугах, которые предоставляют информацию о работе услуги в контексте целевых показателей SLA. Эти отчеты должны содержать детальную информацию обо всех сторонах услуги и ее предоставления, включая текущую и прошлую производительность, слабости и «бреши», основные события, запланированные изменения, текущий и будущий объем работы, планы и деятельность по улучшению. •План совершенствования услуг (SIP); •шаблоны документов для составления SLA, SLR, OLA и других соглашений; Участники процесса: •ИТ комитет При оценке процесса можно выделить следующие типы индикаторов: субъективные индикаторы производительности. •улучшение удовлетворенности заказчиков предоставляемыми услугами объективные индикаторы производительности. •количество или процент достигнутых целевых показателей; •количество «брешей» в услугах; •количество услуг с актуальными SLA; •количество услуг с регулярно формируемыми отчетами и обзорами. Управление уровнем сервисов базируется на важных документах: •Соглашение об Уровне Услуг (Service Level Agreement SLA) •Соглашение об Уровне Сопровождения (Operational Level Agreement OLA) •Контрактах (Underpinning Contracts) Соглашение об Уровне Услуг (Service Level Agreement SLA) – документированное и согласованное соглашение между ИТ сервис провайдером и клиентами. Различают: •Соглашение на уровне сервиса (Service-based SLA) •Соглашение на уровне пользователей (Customer-based SLA) •Многоуровневое соглашение (Multi-level SLA) Соглашение на уровне сервиса (Service-based SLA) – один сервис одно соглашение. Описывает один тип услуг для всех пользователей этой услуги. Например, услуга электронной почты для всех ее пользователей. Преимуществом данного подхода является его простота. Недостатком то, что разным типам пользователей может потребоваться разный уровень услуги или же они могут иметь различные преимущества с точки зрения инфраструктуры. Соглашение на уровне пользователей (Customer-based SLA) – Одно соглашение на все сервисы для одного клиента. Многоуровневое соглашение (Multi-level SLA) – Соглашение на уровне организации и т п. и может включать три уровня: •уровень корпорации – покрывает базовые особенности, подходящие для каждого сотрудника организации. •уровень пользователей – покрывает все особенности, относящиеся к конкретной группе пользователей или бизнес-единице в части используемых ими услуг; •уровень услуг – покрывает все особенности, относящиеся к конкретной услуге в отношении конкретной группы пользователей. Соглашение об Уровне Сопровождения (Operational Level Agreement OLA) – документированное и согласованное соглашение между ИТ сервис провайдером и третьей стороной той же организации, что оказывает содействие в предоставлении сервисов. Как пример может быть соглашение с ИТ департамента с административным департаментом, обслуживающим инженерные службы и системы обеспечения. В качестве требований предъявляемым к SLA и шагам можно отнести: •формулировка SLA должна быть ясной и полной. •Утверждение формы SLA, •Нахождения баланса между тем, что хочется, и тем, что объективно возможно обеспечить. •Разработать механизмы для мониторинга. Измерение пользовательской удовлетворенности отлично от измерения производительности, которую можно и нужно максимально автоматизировать. Пользовательская удовлетворенность является субъективным фактором. Удовлетворенность пользователей = восприятие – ожидания. Если это значение нулевое или больше нуля, то заказчик удовлетворен. Чтобы измерить восприятие заказчика можно использовать следующие методы и средства: •периодические опросы и анкетирование; •обратная связь •телефонный опросы; •анализ достоинств и недостатков. Обзор результатов внедрения является частью процесса Управления изменениями. Обзор результатов внедрения (Post Implementation Review или PIR) – обзор, выполняемый после внедрения изменения проекта. Он определяет успешность изменения проекта и выявляет возможности для улучшения. Для поставщика услуг важно показать заказчикам то, что он внимательно относится к их мнению и вносит соответствующие коррективы и улучшения в предоставляемые услуги. Типовая модель Service Level Agreement должно включать следующие разделы: •Определение предоставляемого сервиса, стороны, вовлеченные в соглашение, и сроки действия соглашения. •Дни и часы, когда сервис будет предлагаться, включая тестирование, поддержку и модернизации. •Число и размещение пользователей и/или оборудования, использующих данный сервис. •Описание процедуры отчетов о проблемах, включая условия эскалации на следующий уровень. Должно быть включено время подготовки отчета. •Описание процедуры запросов на изменение. Может включаться ожидаемое время выполнения этой процедуры. •Спецификации целевых уровней качества сервиса, включая: °Средняя доступность, выраженная как среднее число сбоев на период предоставления сервиса °Минимальная доступность для каждого пользователя °Среднее время отклика сервиса °Максимальное время отклика для каждого пользователя °Средняя пропускная способность °Описания расчета приведенных выше метрик и частоты отчетов •Описание платежей, связанных с сервисом. Возможно, как установление единой цены за весь сервис, так и с разбивкой по уровням сервиса. •Ответственности клиентов при использовании сервиса (подготовка, поддержка соответствующих конфигураций оборудования, программного обеспечения или изменения только в соответствии с процедурой изменения). •Процедура разрешения конфликтов. Множество факторов может послужить триггерами для внесения изменений в сервисное соглашение: •изменения в Портфеле услуг, •Новые требования бизнеса, •Новые требования регулятора, •Новые или измененные услуги; •нарушения в услуге; •положительные или отрицательные отзывы; •изменения в стратегии или политиках. |