1 задание. Вадим Алджанов итархитектура от а до Я Теоретические основы. Первое
 Скачать 8 Mb.
|
|
ЭТАП ВНЕДРЕНИЯ (Transition Stage) Введение Цели этапа Внедрения: •Проектирование новых и изменение имеющихся сервисов для организации •Формирование процесса передачи сервиса в эксплуатацию. •Гарантирование что сервис может быть управляем, •Эффективное планирование и управление потоком изменений •Гарантирование что сервис соответствует бизнес требованиям, •Гарантирование что сервис сопровождается и поддерживается на должном уровне •Гарантирование что сервис соответствует требованиям Пакет Сервис Дизайна (Service Design Package SDP). •Передача сервиса в «рабочую» среду •планирование/управление мощностями и ресурсами для комплектования, сборки, тестирования и запуска в промышленную эксплуатацию услуг, а также обеспечение функционирования услуг в соответствии с требованиями инвесторов и заказчиков; •построение точной и последовательной системы оценки мощности услуг и формирование перечня рисков прежде, чем новая или измененная услуга будет выпущена в промышленную эксплуатацию; •формирование набора активов услуг и конфигураций, которые попадают на этап Внедрения, и управление ими; •предоставление информации, необходимой для принятия решений о введении услуги в промышленную эксплуатацию после тестирования; •предоставление эффективных и повторяемых механизмов для сборки и инсталляции, которые могут быть использованы для развертывания релизов в среде промышленной эксплуатации и среде тестирования; •обеспечение управления, поддержки и корректной эксплуатации услуг в соответствии с требованиями, определенными на этапе Проектирования. •планирование ресурсов и мощностей, необходимых для комплектования, сборки, тестирования, публикации, развертывания и вывода новых или измененных услуг в промышленную эксплуатацию; •предоставление поддержки для персонала в рамках Внедрения; •планирование изменений, необходимых для эффективного управления активами заказчиков, активами услуг и конфигурациями; •ведение отчетности обо всех проблемах, рисках и расхождениях перед заинтересованными сторонами и теми, кто ответственен за принятие решений; •координация проектов, поставщиков и контрактов, поддерживающих услуги. Задачами этапа Внедрения являются: •определить ожидания заказчиков относительно того, как новая или измененная услуга поможет их бизнесу; •помочь в интеграции новой или измененной услуги в бизнес-процессы заказчиков; •уменьшить разницу между прогнозируемой и реальной производительностью; •уменьшить количество известных ошибок и рисков на этапе запуска новой или измененной услуги в промышленную эксплуатацию; •обеспечить то, что услугу можно будет использовать в соответствии с установленными для нее требованиями и ограничениями. Этап Внедрения предоставляет ценность для бизнеса тем, что: •улучшает способность адаптироваться к новым требованиям или обстоятельствам на рынке; •улучшает управление на уровне внедрения в рамках поглощений, разъединений компаний, приобретения или перемещения услуг; •увеличивает количество успешных для бизнеса изменений и релизов; •улучшает точность прогнозирования относительно уровня и качества новых или измененных услуг; •улучшает согласованность с требованиями бизнеса и руководства; •уменьшает количество расхождений между утвержденными бюджетами/планами и реальностью; •увеличивает продуктивность персонала вследствие улучшения планирования и использования новых или измененных услуг; •уменьшает случаи временной приостановки или изменения контрактов на программное и аппаратное обеспечение вследствие соединения или разъединения компонентов; •улучшает понимание уровня риска во время изменения и после него. Данный этап определяется следующими процессами (7): •Управление процессом передачи сервиса и поддержка •Управление процессом изменений •Управление ИТ активами и конфигурацией •Управление релизами и внедрением •Управление тестированием и внедрением •Оценка изменений •Управление базой знаний Входы, поступающие с этапа Построения стратегии, влияют на подход, структуры и ограничения этапа Внедрения: •Портфель услуг; •Портфель заказчиков – база данных или структурированный документ, используемый для хранения информации обо всех Заказчиках поставщика услуг; •Портфель договоров – база данных или структурированный документ, используемый для управления договорами на оказание услуг или Соглашениями между поставщиками услуг и их заказчиками; модель жизненного цикла услуги; политики; стратегии; ограничения; архитектуры; требования к Внедрению; План управления услугами. Этап Проектирования услуг является источником триггеров или механизмов запуска для этапа Внедрения. В первую очередь это проектная документация (SDP), которую необходимо реализовать. Она включает в себя следующие компоненты: определение услуги; структура услуги; финансовая модель и модель затрат; модель мощностей/ресурсов; модель интеграции процесса Управления услугами; модель эксплуатации услуги; спецификация дизайна и интерфейса; дизайн релиза; критерии приемки; Запросы на изменения (RFC). Этап Непрерывного улучшения услуг предоставляет на вход этапа Внедрения информацию в терминах предлагаемых улучшений политик, практик и процессов внедрения. Этап Эксплуатации предоставит на вход этапа Внедрения информацию для тестирования и приемки услуг в терминах достижения услугами требуемых показателей. Выходами этапа Внедрения являются: •утвержденная документация для релиза и развертывания услуг; •обновленный Пакет Услуг. Пакет услуг (Service Package) – детализированное описание услуги, доступной для предоставления заказчикам; •обновленные Каталог услуг и Портфель услуг; •документация для внедряемых или списываемых услуг. Можно выделить два типа процессов этапа Внедрения: Процессы, поддерживающие жизненный цикл услуги: •Управление изменениями; •Оценка услуг и Управление конфигурациями; •Управление знаниями. Процессы в рамках Внедрения: •Планирование и поддержка Внедрения; •Управление релизами и развертыванием; •Тестирование и подтверждение услуг; •Оценка. Планирование Внедрения и Поддержки (Transition Planning & Support TPS) Процесс Планирования Внедрения и Поддержки сервиса является частью этапа «Внедрения». Данный процесс отвечает на такие вопросы как: •Формирование процесса внедрения сервиса. •Формирование процесса поддержки сервиса. Деятельность по процессу: •Утверждение процесса Внедрения и Поддержки сервисов •учет операционных требований и требований проектирования в планах Внедрения; •управление деятельностями в рамках Внедрения; •управление процессами, рисками и расхождениями в рамках Внедрения; •взаимодействие с заказчиками, пользователями и другими заинтересованными сторонами в вопросах, касающихся внедрения; •мониторинг и улучшение производительности Внедрения как процесса. •Формирование стратегии внедрения •Определяет план внедрения и распределение ресурсов •Проверка и принятие SDP, Service Acceptance Criteria and evaluation report Внедрение требует внимательного подхода и последовательных действий. Первое, что необходимо определить – Стратегия Внедрения. Она определяет общий подход организации к внедрению и должна рассматривать следующее: Цели Внедрения; •контекст внедрения (заказчики, договора и т. п.); •охват – то, что входит и не входит в рамки Внедрения; •применяемые стандарты, соглашения, требования регуляторов и контрактов; •организации и инвесторы, вовлеченные во Внедрение; Структура Внедрения: •применяемые политики, процессы и практики; •роли и ответственности; •распределение ресурсов в рамках Внедрения; •формирование требований к подготовке и обучению; механизм авторизации для доступа к релизам и изменениям; •использование накопленного опыта, практики и данных; •распределенные ресурсы и услуги, поддерживающие Внедрение; •критерии успеха для каждой стадии Внедрения, а также остановки или перезапуска деятельностей в рамках Внедрения; •определение требований и содержания новой или измененной услуги в контексте Внедрения; •персонал – назначение на роли, обучение и т. п.; Второй стадией является подготовка к Внедрению. На этой стадии проверяются и собираются все входы процессов, наличие необходимых конфигураций и общая готовность к Внедрению. В частности, детально рассматривается проектная документация (SDP), поступившая с этапа Проектирования. Именно она во многом определяет Внедрение. Подход к Внедрению: •Модель Внедрения; •планы управления изменениями, активами, конфигурациями и знаниями; •планирование затрат, ресурсов и оценочных работ; •подготовка к Внедрению; •оценка; •комплектование, сборка, развертывание и ранняя поддержка релиза; •контроль и управление проблемами, ошибками, инцидентами и т. п. •мониторинг процессов и формирование отчетности; •система измерения производительности услуг; •ключевые показатели производительности и цели по улучшению. •выходы деятельностей в рамках Внедрения, в том числе документация. Следующая стадия – планирование и координация Внедрения. План Внедрения описывает задачи и действия, необходимые для передачи релиза на тестирование или промышленную эксплуатацию. Одним из основных вопросов является распределение ресурсов для конкретных деятельностей в рамках Внедрения. Набор планов внедрения находится между Стратегией внедрения и планами низших уровней – планами релизов, сборки, тестирования и т. п. Далее необходимо обеспечить поддержку Внедрения. Сюда относятся вопросы взаимодействия со всеми заинтересованными лицами, мониторинга производительности услуг и обеспечение обратной связи с другими этапами жизненного цикла. Формирование отчетности о ходе процессов и доведение ее до руководства и заинтересованных лиц позволит сделать выводы о соответствии планам, стратегиям и стандартам, а также эффективности Внедрения в целом. Входы процесса: Процесс Управление Дизайном сервисов Процесс Управления Требованиями Процесс Управления Доступностью ИТ архитектура RFC CMDB CMS SKMS Рекомендации CAB SLAM отчеты Выходы процесса: Подписанный протокол решения ИТ комитета Политики Процедуры Service Provider Interfaces SPIs Роли и ответственности Оценка планирования ресурсов по внедрению Подготовка к внедрению Формирование требований по обучению Авторизация изменений и релизов Стратегия Внедрения Набор планов Внедрения. Участники процесса: ИТ комитет ИТ архитектор Руководители ИТ подразделений Экспертная группа Проектная группа Service Transition Manager Early Life Support Ключевые показатели производительности процесса: •количество релизов, которые соответствуют согласованным требованиям заказчиков по затратам, качеству, охвату и временным рамкам; •уменьшение несоответствия между тем, что получается на практике, и тем, что планировалось; •увеличение удовлетворенности пользователей и заказчиков планами и коммуникациями, которые позволяют настраивать бизнес-деятельность в соответствии с планами Внедрения; •уменьшение количества рисков, вопросов и задержек, вызванных некорректным планированием. Управление Изменениями (Change Management CHM) Процесс Управления Изменениями является частью этапа «Внедрения». Данный процесс отвечает на такие вопросы как: •Формирование процесса управления изменениями. •Кто ИНИЦИИРУЕТ (RAISED) запрос на изменения •Какова ПРИЧИНА (REASON) запроса на изменения •Какова ОТДАЧА (RETURN) требуется от запроса на изменения •Какие РИСКИ (RISKS) влечет в себе запрос на изменения •Какие РЕСУРСЫ (RESOURCES) требует выполнения запроса на изменения •Кто ОТВЕТСТВЕННЫЙ (RESPONSIBLE) за создание, тестирование и выполнения запроса на изменения •Какова СВЯЗЬ (RELATIONSHIP) между этим запросом на изменения и другими Цели процесса: •использования стандартных методов и процедур для быстрой и эффективной реализации изменений; •фиксации всех изменений в активах услуг и конфигурациях в Системе Управления конфигурациями (CMS); •оптимизации всех рисков для бизнеса. Управление изменениями представляет ценность для бизнеса тем, что: •категорирует цели изменений бизнеса и заказчиков и помогает их осуществить; •реализует изменения, которые соответствуют потребностям заказчиков, одновременно с оптимизацией затрат; •старается выполнять требования закона, контрактов, руководства и регуляторов; •уменьшает количество неудавшихся изменений и, соответственно, количество сбоев, остановок и простоев услуг; •осуществляет изменения в установленном бизнесом временном интервале; •следит за изменениями на всем жизненном цикле услуг; •старается обеспечить лучшие показатели в аспектах качества, времени и затрат; •оценивает риски, сопутствующие внедрению; •помогает увеличить продуктивность работы персонала тем, что минимизирует нарушения и сбои, а, следовательно, улучшает доступность услуг; •уменьшает Среднее время восстановления услуг (MTRS) посредством быстрой и успешной реализации изменений; •сотрудничает с процессом изменения бизнеса для выявления возможностей улучшения бизнеса. Хорошо структурированные и запланированные изменения помогают бизнесу сократить издержки и повысить эффективность. Модель процесса изменения должна включать следующее: •шаги, которые должны быть предприняты для реализации изменения, в том числе разрешение проблем и непредвиденных событий; •хронологический порядок шагов; •ответственности и распределение обязанностей; •границы, в том числе временные, каждой деятельности в рамках процесса; Ни одно изменение не должно осуществляться без четкого планирования действий в случае, если оно будет неудачным – «планирование исправления». В идеале должен быть некий план «backup», который позволит организации вернуться в состояние, предшествующее изменению. Только посредством оценки того, какие действия по исправлению возможны в конкретной ситуации, можно определить риски, соответствующие изменению. Деятельность в рамках процесса Управления изменениями включают: •планирование и контроль изменений; •составление расписаний для изменений и релизов; •обеспечение коммуникации между всеми участниками и компонентами; •авторизация к изменениям (то есть разрешения доступа тем, кто уполномочен вносить изменения) и принятие решений относительно изменений; •формирование планов по исправлению, которые будут задействованы в случае неудачных изменений; •измерение и контроль; •формирование управленческой отчетности; •оценка влияния изменения; •непрерывное улучшение. •Утверждение процесса Управления Изменениями •Формирование комитета по Управлению Изменениями •Формирование списка «пред-утвержденных» изменений •Изменение Уровня Предоставления Сервисов (Service Level Agreement SLA) •Принятие решения по выводу ИТ сервиса из сопровождения Стандартные действия при реализации отдельных изменений: •создание Запроса на изменение (RFC); •пересмотр и проверка RFC, фильтрация изменений; •оценка и определение изменения: •установить уровень управления изменением; •определить участников процесса; •оценить мотивацию бизнеса, издержки, риски и выгоды, связанные с изменением; •запросить независимую оценку изменения. •утверждение изменения (в том числе определение механизмов авторизации к нему); •формирование планов обновлений; •координация реализации изменения; •обзор и завершение изменения. При внедрении процесса управления изменениями необходимо определить следующие важные атрибуты: Определить, по возможности категоризацию воздействия с указанием метрик: •Высокое (High) воздействие – Изменение воздействует на всех пользователей или критичен для бизнеса или Изменение затрагивает критические компоненты сервиса •Среднее (Medium) воздействие – Изменение воздействует на (значительную или нет) группу пользователей или бизнеса, или Изменение затрагивает критические, но зарезервированные компоненты сервиса •Низкое (Low) воздействие – Изменение воздействует на одного пользователей или не критичен для бизнеса, или Изменение затрагивает не критические или второстепенные компоненты сервиса Категоризацию срочности с указанием метрик: •Высокая (High) срочность – Изменение требует немедленного вмешательства или выполнения •Средняя (Medium) срочность – Изменение требует вмешательства, но время разрешения в пределах SLA •Низкая (Low) срочность – Изменение не требует немедленного вмешательства Определить, по возможности уровень риска, при применении и не применении данных изменений: •Высокий (High) риск воздействие •Среднее (Medium) риск воздействие •Низкое (Low) риск воздействие •Воздействие не определённо (Not assessed) Порядок реагирования для каждой категории изменений: •Время выполнения изменений – максимальное время, в течении которого ИТ департамент обязуется выполнить изменения. Определение источников поступления изменений: •Запросы на изменения со стороны бизнеса (Процессы управления доступностью, требованиями) •Запросы на изменения со стороны департамента Безопасности •Анализ инцидентов (Процесс управления инцидентами) •Анализ запросов (Процесс управления запросами) •Анализ проблем (Процесс управления проблемами) •Мониторинг событий и логов (Процесс управления Событиями) •Анализ релизов (Процесс управления Релизами) •Запросы на изменения со стороны ИТ департамента (Этап Улучшения Сервиса) Статусы изменений: •Инициирован (Initiate) •Одобренный (Approved) •Активный (In progress) •В ожидании (On pending) •Приостановленный (On hold) •Проверенный (Validated and Reviewed) •Выполненный (Completed) •Закрытый (Closed) •Активность проигнорирована (skipped) Классификация изменений по типам и подтипам (зависит от специфики организации, предпочтениям и т п): •Стратегические изменения •Тактические изменения •Оперативные изменения •Стандартные изменения •Стандартные «пред-утвержденные» изменения •Экстренные изменения •Не классифицированные изменения •«Стандартизированные» изменения •Заранее «одобренные» Изменения Определение групп выполнения и подтверждения изменений. Зависит от организационной структуры ИТ департамента, классификации изменений и т п: •Оператор центра Поддержки Пользователей •Группы подтверждения изменений (по процессам) •Комитет по утверждению изменений •Менеджер по управлению изменениями •Первая линия поддержки •Вторая линия поддержки •Третья линия поддержки •Четвертая линия – поддержка производителя Результаты выполнения изменений: •Удачно выполненный (Successfully implemented) •Выполненный с незначительными проблемами (Implemented with Issues) •Частично выполненный (Partially implemented) •Не выполненный (Failed) •Отказанный (Rejected) •Отозванный (Cancelled) •Не одобренный (Unauthorized) Определение типовых под-процессов (шаблонов) для различных изменений Определение метрик и показателей оценки эффективности и результативности процесса Кроме элементов, выше указанных, необходимо также определить следующие элементы: •порядок информирования пользователя, сотрудника ИТ и менеджера проекта или супервайзера на различных этапах жизни изменений. •Метрики соглашений •План внедрения изменений (Implementation Plan) •Оценка рисков при внедрении или не внедрении изменений (Risk Assessment Plan) •План тестирования изменений (Test Plan) •План отката изменений (Back out Plan) В процессе управления изменениями анализируется возможность и формируется список «заранее одобренных» изменений или изменений, которые можно автоматизировать. В процессе анализа используются основные атрибуты: •Воздействие изменений •Вероятность возникновения •Простота и ясность операций Входами процесса Управления изменениями являются: Политики и стратегии изменений и релизов; Запросы на изменения; Предложение изменения; Планы изменения, внедрения, релиза, развертывания, тестирования, оценки и исправления; График изменений и Ожидаемый простой услуги (PSO); активы и конфигурационные единицы; результаты и отчеты тестирования/оценки. Выходами процесса Управления изменениями являются: Подписанный протокол решения ИТ комитета отклоненные RFC; утвержденные RFC; изменения услуг и инфраструктуры – результат утвержденных RFC; новые, измененные или распределенные активы, или конфигурационные единицы; график изменений; пересмотренный Ожидаемый простой услуги (PSO); утвержденные планы изменений; решения и действия по реализации изменений; документация и записи изменений; отчеты Управления изменениями. Участники процесса: ИТ комитет Комитет по Управлению Изменениями (Change Advisory Board CAB) Комитет по Управлению Экстренными Изменениями (Emergency Change Advisory Board ECAB) Ключевые показатели производительности для Управления изменениями должны быть связаны с целями бизнеса, в частности, отражать сокращение издержек, увеличение доступности и надежности услуг, которые стали возможными в результате реализованных изменений. Такими показателями могут быть: количество реализованных изменений, которые смогли удовлетворить согласованные требования заказчиков в качестве/издержках/времени; выгода изменений – сравнение «ценность сделанных улучшений “+” предотвращенное негативное влияние» и стоимости реализации изменений; уменьшение количества сбоев услуг, дефектов и дополнительных работ; уменьшение количества неутвержденных изменений; уменьшение количества невыполненных запросов на изменение; уменьшение количества незапланированных изменений и экстренных исправлений; процент успешных изменений – отношение изменений, признанных успешными, к общему количеству утвержденных запросов на изменение; уменьшение количества изменений, в рамках которых есть работы по исправлению; уменьшение количества неудавшихся изменений; уменьшение количества инцидентов, связанных с изменениями; Критерии эффективности – (KPI) Количество изменений Количество «стандартных» изменений Количество срочных изменений Количество важных изменений Количество «не авторизованных» изменений Отношение изменений к инцидентам Количество изменений со статусом «overdue» Количество изменений, выполненных в срок Количество изменений со статусом «rejected» Количество изменений, вызванных инцидентами Количество изменений, вызванных запросами Количество изменений, вызванных событиями Количество изменений, вызванных проблемами Средний срок закрытия изменений Процесс управления изменениями один из наиболее важных и сложных процессов при построении системы управления ИТ сервисами, так как требует вовлеченность различных |