Внедрение как этап жизненного цикла услуг

Внедрение как этап жизненного цикла услуг 7.1. Внедрение как этап жизненного цикла услуг Многие инновации в бизнесе реализуются посредством проектов с участием IT. При этом не важно, речь идет о незначительных операционных улучшениях или глобальных событиях, связанных с преобразованием целого бизнеса, - в конечном итоге это приводит к изменению. В частности, использование новой или измененной услуги также является изменением для бизнеса. Этап Внедрения гарантирует то, что запланированные и спроектированные на предыдущих стадиях жизненного цикла услуги смогут достичь ожидаемых бизнесом и IT результатов на практике. Следует отметить, что в некоторой русскоязычной литературе этап Внедрения называется Преобразованием услуг, так как transition с английского переводится как перемещение/переход. Таким образом, этап Внедрения является чем-то вроде буфера для проверки услуг перед непосредственной эксплуатацией. Прежде чем говорить о Внедрении, необходимо определить основные термины в его контексте. Преобразование (Transition) - изменение в состоянии, соответствующее перемещению услуги или конфигурационной единицы из одной стадии жизненного цикла к следующей стадии. Релиз (Release) - набор аппаратного обеспечения, программного обеспечения, документации, процессов или других компонентов, которые необходимы для внедрения одного или нескольких согласованных изменений в услугах. Содержание каждого релиза управляется, тестируется и развертывается как отдельная сущность. Запрос на изменение (Request for Change или RFC) - формальное предложение на реализацию Изменения. RFC включает в себя детальное описание предложенного изменения, и может быть записано в бумажном или электронном формате. Тестирование (Test) - деятельность, которая верифицирует, что конфигурационная единица, услуга, процесс, и т.п., соответствует спецификации или согласованным требованиям. Сборка(Build) - деятельность по компоновке одного и более конфигурационных единиц для формирования части услуги. Термин Сборка также используется в отношении релиза, который утвержден для распространения. Например, Сборка сервера или Сборка ноутбука. Развертывание (Deployment) - деятельность, отвечающая за перемещение нового или измененного оборудования, ПО, документации, процесса, и т.п., в среду промышленной эксплуатации. Поддержка в начале эксплуатации (Early Life Support) - поддержка, предоставляемая в отношении новой или измененной услуги в течение некоторого времени непосредственно после того, как услуга была введена в эксплуатацию. Во время Поддержки в начале эксплуатации поставщик услуг может пересматривать KPI, уровни услуги и наблюдаемые пороговые значения, а также задействовать дополнительные ресурсы для Управления инцидентами и Управления проблемами. Среда (Environment) - подмножество ИТ-инфраструктуры, которое используется в различных целях. Для сложных Сред есть возможность совместно использовать конфигурационные единицы, например Среды тестовой и промышленной эксплуатации могут использовать различные разделы на одном майнфрейме. Также используется в термине физической среды для обозначения помещения, кондиционирования, системы питания и т.п. Среда промышленной эксплуатации (Live Environment) - управляемая среда, содержащая конфигурационные единицы в режиме промышленной эксплуатации, используемые для предоставления услуг. Среда тестирования (Test Environment ) - контролируемая среда, используемая для тестирования конфигурационных единиц, сборок, услуг, Процессов и т.п. Среда сборки (Build Environment) - контролируемая среда, в которой собираются (компонуются) приложения, услуги и другие сборки перед их передачей в Среду тестирования или Среду промышленной эксплуатации. Приемка(Acceptance) - формальное соглашение, определяющее, что услуга, процесс, План или другой результат завершен, является правильным, надежным и отвечает установленным требованиям. Приемке обычно предшествует оценка или тестирование, приемка часто обязательна для перехода к выполнению следующего этапа проекта или процесса. Основные цели этапа Внедрения: • планирование/управление мощностями и ресурсами для комплектования, сборки, тестирования и запуска в промышленную эксплуатацию услуг, а также обеспечение функционирования услуг в соответствии с требованиями инвесторов и заказчиков; • построение точной и последовательной системы оценки мощности услуг и формирование перечня рисков прежде, чем новая или измененная услуга будет выпущена в промышленную эксплуатацию; • формирование набора активов услуг и конфигураций, которые попадают на этап Внедрения, и управление ими; • предоставление информации, необходимой для принятия решений о введении услуги в промышленную эксплуатацию после тестирования; • предоставление эффективных и повторяемых механизмов для сборки и инсталляции, которые могут быть использованы для развертывания релизов в среде промышленной эксплуатации и среде тестирования; • обеспечение управления, поддержки и корректной эксплуатации услуг в соответствии с требованиями, определенными на этапе Проектирования. Задачами этапа Внедрения являются: • определить ожидания заказчиков относительно того, как новая или измененная услуга поможет их бизнесу; • помочь в интеграции новой или измененной услуги в бизнес-процессы заказчиков; • уменьшить разницу между прогнозируемой и реальной производительностью; • уменьшить количество известных ошибок и рисков на этапе запуска новой или измененной услуги в промышленную эксплуатацию; • обеспечить то, что услугу можно будет использовать в соответствии с установленными для нее требованиями и ограничениями. Этап Внедрения предоставляет ценность для бизнеса тем, что: • улучшает способность адаптироваться к новым требованиям или обстоятельствам на рынке; • улучшает управление на уровне внедрения в рамках поглощений, разъединений компаний, приобретения или перемещения услуг; • увеличивает количество успешных для бизнеса изменений и релизов; • улучшает точность прогнозирования относительно уровня и качества новых или измененных услуг; • улучшает согласованность с требованиями бизнеса и руководства; • уменьшает количество расхождений между утвержденными бюджетами/планами и реальностью; • увеличивает продуктивность персонала вследствие улучшения планирования и использования новых или измененных услуг; • уменьшает случаи временной приостановки или изменения контрактов на программное и аппаратное обеспечение вследствие соединения или разъединения компонентов; • улучшает понимание уровня риска во время изменения и после него. Этап Внедрения находится между этапами Проектирования и Эксплуатации в жизненном цикле услуг. Именно с этими этапами происходит наиболее тесное и непрерывное взаимодействие. Тем не менее, у этапа Внедрения есть связи со всеми другими этапами жизненного цикла услуг. Входы, поступающие с этапа Построения стратегии, влияют на подход, структуры и ограничения этапа Внедрения: 1. Портфель услуг; 2. Портфель заказчиков - база данных или структурированный документ, используемый для хранения информации обо всех Заказчиках поставщика услуг; 3. Портфель договоров - база данных или структурированный документ, используемый для управления договорами на оказание услуг или Соглашениями между поставщиками услуг и их заказчиками[1]; 4. модель жизненного цикла услуги; 5. политики; 6. стратегии; 7. ограничения; 8. архитектуры; 9. требования к Внедрению; 10. План управления услугами. Этап Проектирования услуг является источником триггеров (или механизмов запуска) для этапа Внедрения. В первую очередь это проектная документация (SDP), которую необходимо реализовать. Она включает в себя следующие компоненты: 1. определение услуги; 2. структура услуги; 3. финансовая модель и модель затрат; 4. модель мощностей/ресурсов; 5. модель интеграции процесса Управления услугами; 6. модель эксплуатации услуги; 7. спецификация дизайна и интерфейса; 8. дизайн релиза; 9. критерии приемки; 10. Запросы на изменения (RFC). Этап Непрерывного улучшения услуг предоставляет на вход этапа Внедрения информацию в терминах предлагаемых улучшений политик, практик и процессов внедрения. Этап Эксплуатации предоставит на вход этапа Внедрения информацию для тестирования и приемки услуг в терминах достижения услугами требуемых показателей. Выходами этапа Внедрения являются: 1. утвержденная документация для релиза и развертывания услуг; 2. обновленный Пакет Услуг. Пакет услуг (Service Package) - детализированное описание услуги, доступной для предоставления заказчикам; 3. обновленные Каталог услуг и Портфель услуг; 4. документация для внедряемых или списываемых услуг. В ITIL выделено два типа процессов этапа Внедрения: 1. процессы, поддерживающие жизненный цикл услуги: ◦ Управление изменениями; ◦ Оценка услуг и Управление конфигурациями; ◦ Управление знаниями. 2. процессы в рамках Внедрения: ◦ Планирование и поддержка Внедрения; ◦ Управление релизами и развертыванием; ◦ Тестирование и подтверждение услуг; ◦ Оценка. Этап Построения стратегии предоставляет систему для определения услуги. Ценность услуги определяется в контексте потребностей заказчика. Использование активов поставщика услуг для предоставления услуг бизнесу и заказчикам представлено на рис. 7.1. Рис. 7.1.  Активы, необходимые для предоставления услуг Здесь под активами понимаются ресурсы и возможности поставщика услуг. Услуги предоставляют ценность посредством увеличения производительности активов бизнеса или уменьшения рисков. Как уже отмечалось ранее, ценность услуги выражается в терминах качества и полезности. Полезность - мера увеличения производительности активов заказчика. Качество - уверенность в том, что услуга в процессе предоставления будет выполнять ряд установленных условий. Выделяют три основные характеристики качества услуг: • доступность и мощность услуг; • обеспечение того, что активы заказчика будут получать полезность, даже в случае неблагоприятных событий или сниженного уровня услуг; • обеспечение безопасности для наиболее ценных активов заказчика. При этом в зависимости от конкретной ситуации один из аспектов качества может иметь большее значение для заказчика. 7.2. Основные принципы этапа Внедрения Приведем фундаментальные принципы этапа Внедрения из публикации "ITILv3. Service Transition". 1. Определение и осуществление формальной Политики Внедрения Позиция: Формальная Политика Внедрения должна быть определена, документирована и утверждена руководством. Ее необходимо довести до всех сотрудников организации, поставщиков и партнеров, которые имеют отношение к Внедрению. Принципы: 1. в политике должны быть четко определены цели, а любые несовпадения с политикой должны быть исправлены, либо исключены; 2. необходимо обеспечить соответствие Политики Внедрения политикам Управления услугами; 3. люди, ответственные за формирование политики, должны демонстрировать свою заинтересованность в ее выполнении; 4. использовать процессы, которые объединяют команды; смешивать компетенции в рамках ведения отчетности и распределения ответственностей; 5. предоставлять изменения в релизах; 6. затрагивать вопросы развертывания уже на этапах планирования и проектирования релизов. Лучшие практики: Получать формальные подписи тех, кто участвует в разработке Политики: менеджеров, спонсоров и других людей, которые принимают решения. 2. Осуществление изменений в услугах через Внедрение Позиция: Все изменения, касающиеся Портфеля услуг и Каталога услуг, проходят через процесс Управления изменениями. При этом все изменения должны быть четко определены и согласованы. Принципы: 1. концентрирование изменений в одной точке минимизирует конфликты между изменениями, последующие нарушения и сбои в среде промышленной эксплуатации; 2. люди, которые не имеют прав вносить изменения и выпускать услуги в промышленную эксплуатацию, не должны иметь доступ к процессам Внедрения; 3. тесное взаимодействие с этапом Эксплуатации повысит мобильность и сделает возможным организационные изменения; 4. увеличение знаний и опыта в вопросах эффективного улучшения услуг и среды промышленной эксплуатации; 5. каждый релиз должен быть спроектирован на основе Запроса на изменение и пройти сквозь процесс Управления изменениями, что обеспечит эффективный контроль; 6. для управления изменениями необходимо использовать стандартизованные методы и процедуры с целью уменьшения влияния инцидентов, связанных с изменениями, на непрерывность бизнеса, качество услуг и доработки; 7. все обновления для изменений и релизов фиксируются в контексте активов услуг и конфигурационных единиц в Системе Управления Конфигурациями(CMS). Лучшие практики: ◦ каждое изменение должно быть четко определено; ◦ необходимо разделять внутренние и внешние изменения; ◦ изменения должны быть оправданы с помощью четкого бизнес-кейса; ◦ изменения определены в проектной документации, которую Внедрение может использовать для сравнения производительности, полученной на практике, и "предсказанной" в документации; ◦ существующий процесс Управления изменениями, возможно, придется стандартизовать и приводить в исполнение; ◦ менеджеры должны участвовать в процессах и это должно быть четко видно инвесторам; ◦ настройка аудита для идентификации всех неавторизованных изменений; ◦ не принимать "запоздавшие" запросы на изменения, которыми невозможно управлять надлежащим образом. 2. Разработка общей структуры и стандартов Внедрения Позиция: Внедрение должно быть построено на стандартных процессах и системах, допускающих многократное пользование. Это позволит улучшить интеграцию отдельных подэтапов Внедрения и уменьшить несогласованность процессов. Принципы: 1. использовать лучшие практики конкретной области как основу для стандартизации Внедрения; 2. контролировать структуру и стандарты Внедрения с помощью Управления изменениями и Управления конфигурациями; 3. гарантировать то, что процессы Внедрения применяются последовательно с регулярными обзорами и аудитами других процессов Управления услугами. Лучшие практики: ◦ публикация стандартов и лучших практик Внедрения; ◦ построение системы для создания последовательных процессов по обеспечению и использованию мощности услуг и построение перечня рисков до и после того как релиз развернут; ◦ предоставить поддерживающие системы, которые позволят автоматизировать процессы с целью уменьшения сопротивления при внедрении; ◦ убедиться в том, что менеджмент понимает необходимость стандартизации процессов в рамках разработки и предоставления улучшений, основанных на четком бизнес-кейсе; ◦ установить уровень вовлеченности менеджмента и инвесторов и предпринять действия по устранению любых "разрывов". 2. Максимальное повторное использование процессов и систем Позиция: Процессы этапа Внедрения должны быть согласованы с процессами организации и связанными с ними системами. Если появляется необходимость в новых процессах, они разрабатываются с максимальным повторным использованием уже имеющихся процессов. Принципы: 1. повторное использование имеющихся процессов и систем там, где это возможно; 2. сбор информации и данных из оригинальных источников с целью уменьшения ошибок и эффективной помощи в случае возникновения необходимости; 3. разработка стандартных моделей Внедрения, которые можно многократно использовать; 4. использование лучших стандартов и практик области в качестве основы для стандартизации с целью объединения результатов от разных поставщиков. Лучшие практики: ◦ интегрировать процессы Внедрения в систему управления качеством; ◦ использовать управленческие практики и общую программу организации; ◦ использовать существующие каналы связи для обеспечения коммуникации в рамках Внедрения; ◦ следовать процессам Управления человеческими ресурсами, финансами, ресурсами, возможностями и общепринятым практикам; ◦ структурировать модели так, чтобы постоянный подход можно было использовать для каждой единицы услуги или окружения с незначительными изменениями при необходимости. 2. Формирование планов Внедрения в соответствии с требованиями бизнеса Принцип: С целью максимизации ценности, предоставляемой изменением, необходимо обеспечить соответствие планов Внедрения требованиям бизнеса и заказчиков. Принципы: 1. сформировать набор ожиданий заказчиков и пользователей относительно производительности и использования новой или измененной услуги на этапе Внедрения; 2. предоставить информацию и процессы для интеграции релиза в бизнес-процессы; 3. с целью повышения удовлетворенности заказчиков обеспечить использование услуги в соответствии с определенными для нее требованиями и ограничениями; 4. с целью максимизации использования услуги заказчиками, инвесторами и пользователями обеспечить их необходимой информацией и знаниями; 5. обеспечить мониторинг и измерение использования услуг, поддерживающих их приложений и технических решений в процессе развертывания и на ранних стадиях поддержки. Это необходимо для того, чтобы гарантировать качественное предоставление услуг прежде, чем этап Внедрения будет завершен; 6. сравнить производительность услуг, полученной на практике, с запланированной на стадии Построения стратегии, и провести мероприятия по сокращению несоответствий в показателях мощности и производительности. Лучшие практики: ◦ использовать лучшие управленческие практики для планирования и управления ресурсами, необходимыми для успешной сборки, комплектования, тестирования и развертывания релиза в промышленную эксплуатацию в рамках установленных затрат, времени и качества; ◦ предоставить четкие, понятные и полные планы, которые обеспечат соответствие проектов изменений бизнеса и заказчиков и планов Внедрения. ◦ управлять вовлеченностью инвесторов и связью с ними. 2. Установление и управление взаимоотношениями с инвесторами Позиция: Для формирования набора требований к новой или измененной услуге в рамках Внедрения необходимо установить и управлять взаимоотношениями с заказчиками, их представителями, инвесторами и поставщиками. Принципы: 1. сформировать набор ожиданий заинтересованных сторон о том, как производительность и использование новой услуги могут помочь изменению бизнеса; 2. улучшать понимание и знания заинтересованных сторон о новых или измененных услугах; 3. предоставлять качественную информацию и накопленный опыт заинтересованным сторонам, чтобы они могли легко получить всю необходимую им информацию о Внедрении. Лучшие практики: ◦ проверить вместе с заинтересованными сторонами то, что новая или измененная услуга может использоваться в соответствии с установленными требованиями и ограничениями; ◦ обмениваться планами Внедрения и релизов с заинтересованными сторонами; ◦ работать вместе с Управлением отношениями с бизнесом и Управлением уровнем услуг для построения взаимоотношений с заказчиками и инвесторами в рамках этапа Внедрения. 2. Установление эффективных контролей и дисциплин Позиция: Установление подходящих контролей и дисциплин в рамках жизненного цикла услуг, которые сделают возможным гладкое внедрение изменений и релизов услуг. Принципы: 1. идентификация и управление всеми активами услуг и конфигурациями с момента их поступления на этап Внедрения; 2. автоматизация деятельности по аудиту там, где это экономически оправдано, с целью обнаружения неавторизованных изменений и несовместимости конфигураций; 3. четко определение того, "кто, где, что и когда делает" в рамках внедрения, для увеличения подотчетности в отношении планов и процессов; 4. определение ролей и ответственностей в рамках Внедрения с целью уменьшения ошибок, появляющихся из-за взаимного непонимания и недостатка контроля; 5. идентификация процессов, основанных на транзакциях, для управления конфигурациями, изменениями и проблемами с целью предоставления информации, необходимой для улучшения контролей. Лучшие практики: ◦ убедиться в том, что роли и ответственности хорошо определены, понятны и управляемы; ◦ назначить людей на каждую роль и управлять назначениями в рамках SKMS или CMS, чтобы предоставить прозрачность о том, кто ответственен за конкретную деятельность; ◦ использовать интегрированные процессы управления инцидентами, проблемами, конфигурациями для измерения качества конфигурационных единиц в рамках жизненного цикла услуг; ◦ гарантировать то, что услуга может использоваться, управляться и поддерживаться в соответствии с требованиями и ограничениями, определенными на этапе Построения стратегии; ◦ убедиться в том, что только компетентный персонал может производить изменения; ◦ проводить аудит процессов и конфигураций с целью обнаружения несоответствий и нарушений, которые могут негативно повлиять на этап Внедрения. 2. Предоставление обмена знаниями и поддержки решений Позиция Этап Внедрения разрабатывает системы и процессы обмена информацией для эффективного использования услуги. Обмен информацией также обеспечивает своевременное принятие решений компетентными людьми. Принципы: 1. предоставлять качественную информацию, данные и знания "нужным людям в нужное время" с целью уменьшения времени для принятия решений; 2. осуществлять обучение пользователей и передачу им необходимой информации с целью уменьшения количества обращений в сервис-деск; 3. повышать качество информации и данных для увеличения удовлетворенности заказчиков и инвесторов при одновременной оптимизации затрат на производство и поддержку; 4. повышать качество документации, относящейся к этапу Внедрения; 5. обеспечить легкий доступ к информации, чтобы те, кому она необходима, не тратили время на долгий поиск. Особенно актуально в отношении критических деятельностей, таких как управление в случае крупных инцидентов. 6. определить единый источник информации, который позволит обмениваться ей в рамках жизненного цикла и с инвесторами с целью обеспечения максимального качества информации и облегчения управления ею; 7. предоставлять полную информацию процессам Управления релизами, изменениями и разработкой, дабы они могли принимать решения о передаче релиза на тестирование или эксплуатацию. Лучшие практики: ◦ предоставление доступа, презентаций и инструментов отчетности для Системы управления знаниями по услугам (SKMS) и Системы управления конфигурациями (CMS); ◦ предоставление удобных интерфейсов доступа к SKMS и CMS для разных людей и ролей, чтобы они могли своевременно принимать необходимые решения; ◦ объединение и публикация предсказуемых и непредсказуемых эффектов изменения, различия актуальной и предсказываемой производительности и мощности, формировать перечень рисков; ◦ убедиться в корректности информации от Управления конфигурациями и Управления активами; ◦ предоставление данных, информации и знаний, необходимых для разрешения проблемных ситуаций (инцидентов и ошибок). 2. Планирование пакетов для релиза и развертывания Позиция: Пакеты для релизов должны быть спланированы и спроектированы так, чтобы их сборка, тестирование, предоставление и передача в промышленную эксплуатацию осуществлялись на согласованных уровнях эффективности, отчетности и затрат. Принципы: 1. политика релизов должна быть согласована с бизнесом и всему другими участниками Внедрения; 2. планирование релизов необходимо производить заблаговременно; 3. использование ресурсов должно быть оптимизировано в рамках Внедрения; 4. необходимо планировать механизмы выпуска и распространения услуг так, чтобы обеспечить целостность компонентов в рамках этапов Внедрения; 5. оценка и управление рисками изъятия или исправления ошибочных релизов; 6. необходимо измерять "успех и неудачи" релизов с целью дальнейшей оптимизации затрат и увеличения эффективности. Лучшие практики: ◦ все обновления релизов должны быть отображены в Системе управления конфигурациями (CMS); ◦ необходимо фиксировать даты релизов и развертывания вместе с относящимися к ним запросами на изменение и проблемами; ◦ процедуры, используемые для управления, развертывания, предоставления, публикации и распространения, должны быть отработаны и проверены: ◦ информация о том, что необходимо для релиза, должна доходить до соответствующих участников процесса Внедрения в виде документов, например, технические требования для среды тестирования. 2. Управление изменениями курса Позиция: Внедрение является длительным и трудоемким процессом, на который влияет множество факторов. Участники должны быть способны распознавать ситуации и обстоятельства, при которых требуется смена или корректировка курса Внедрения. Целью Управления изменениями курса является обучение персонала тому, как распознавать необходимость корректирующих мер и вносить предложения на изменение курса с учетом существующих ограничений. Принципы: 1. способствовать тому, чтобы инвесторы понимали необходимость изменений планов и принимали в них участие; 2. использовать опыт предыдущих коррекций с целью предсказания их необходимости в будущем и повторного использования успешных подходов; 3. собирать информацию от завершенных внедрений и делать ее доступной; 4. управлять изменением курса с помощью Управления изменениями и других подходящих процедур в рамках жизненного цикла услуг. Лучшие практики: ◦ для управления изменениями курса необходимо использовать практики менеджмента и процесса Управления изменениями; ◦ документировать и контролировать все изменения, но без лишней "бюрократии"; ◦ предоставлять информацию об изменениях, которые были применены после соответствующей настройки конфигураций; ◦ при необходимости вовлекать инвесторов в изменения. 2. Проактивное управление ресурсами в рамках Внедрения Позиция: Предоставлять и распределять ресурсы в рамках Внедрения так, чтобы избежать любых задержек. Принципы: 1. определить ресурсы, информацию и навыки, необходимые для осуществления Внедрения; 2. сформировать команду, способную успешно реализовать стратегию Внедрения, проектную документацию и пакет релиза; 3. выделять ресурсы, необходимые для критических деятельностей в рамках Внедрения, с целью предотвращения задержек в их предоставлении; 4. автоматизировать процессы, которые часто повторяются или подвержены ошибкам со стороны персонала, с целью повышения эффективности деятельностей в рамках Внедрения. Лучшие практики: ◦ взаимодействие с управлением персоналом, поставщиками и т.п., с целью определения, управления и использования доступных и подходящих ресурсов; ◦ определение необходимых ресурсов, которые находятся за пределами ITSM, и их использование; ◦ проактивное управление распределением ресурсов с целью минимизации негативного влияния задержки в одном внедрении на другое. 2. Участие на ранних стадиях жизненного цикла услуги Позиция: Необходимо контролировать услугу на ранних стадиях жизненного цикла с целью проверки ее способности предоставлять требуемую ценность. Принципы: 1. использовать различные способы для обнаружения ошибок и сбоев на ранних этапах жизненного цикла услуги. Чем раньше они будут выявлены, тем дешевле будет их устранить; 2. идентифицировать изменения, которые не принесут ожидаемой выгоды, и остановить их до того, как ресурсы будут использованы впустую. Лучшие практики: ◦ вовлекать заказчиков и их представителей в процесс тестирования, чтобы понять, как можно доказать им, что услуга принесет для них выгоду; ◦ вовлекать пользователей в тестирование там, где это возможно, чтобы проверить, как они будут использовать услугу на практике; ◦ использовать предыдущий опыт для определения возможных ошибок проектирования; ◦ предусмотреть и встроить в услугу механизмы, которые позволят контролировать ценность услуги и показывать ее заказчику; ◦ использовать независимые оценку и аудит для установления приемлемости рисков. 2. Гарантировать качество новой или измененной услуги Позиция: Проверять и утверждать предложенные изменения услуг с целью гарантии того, что они удовлетворят требования заказчиков и принесут им выгоду. Принципы: 1. Внедрение должно гарантировать, что предложенные изменения услуг могут быть осуществлены в соответствии с планами, спецификациями и соглашениями в рамках согласованных уровней услуг; 2. убедиться, что команды, вовлеченные в процесс Внедрения, действительно понимают, что пользователи и заказчики хотят получить в результате использования услуг; 3. оценка качества и тестирование должны предоставить комплексную оценку качества новой или измененной услуги, и сопровождающих ее рисков; 4. среда для тестирования должна максимально отражать среду эксплуатации; 5. проектирование и проведение тестирования должны быть максимально независимы от проектировщиков и разработчиков с целью повышения эффективности и разделения обязанностей; 6. осуществлять процессы Управления конфигурациями и Управления проблемами в рамках жизненного цикла услуг с целью измерения и уменьшения известных ошибок, вызванных передачей релизов в промышленную эксплуатацию. Лучшие практики: ◦ понимать приоритеты и процессы бизнеса; ◦ стараться вовлекать все заинтересованные стороны в процессы Внедрения с целью формирования у них доверия; ◦ понимать разницу межу средами тестирования, сборки и рабочей эксплуатации для того, чтобы управлять любыми отличиями и прогнозировать поведение услуги в той или иной ситуации; ◦ оборудование для тестирования должно управляться в рамках Управления изменениями и конфигурациями; ◦ отправной точкой для реализации изменения должна быть информация о текущем состоянии услуги и информация, поступающая с этапа Проектирования; ◦ до публикации и распространения услуги необходимо оценить производительность, качество и затраты, которые были спрогнозированы на этапе Проектирования, в контексте предыдущего опыта и обратной связи с инвесторами; ◦ учитывать обстоятельства и условия, которые будут присутствовать на практике после завершения Внедрения. 2. Проактивное улучшение качества в процессе Внедрения Позиция: Проактивное планирование и улучшение новой или измененной услуги в процессе Внедрения. Принципы: 1. обнаружение и устранение инцидентов и проблем на этапе Внедрения с целью уменьшения вероятности их возникновения на этапе Эксплуатации; 2. проактивное обнаружение и управление инцидентами, проблемами и ошибками на этапе Внедрения, с целью уменьшения затрат, количества доработок и негативного влияния на бизнес; Лучшие практики: ◦ сравнивать значения мощности, производительности и затрат, полученные на практике, с теми, которые были предсказаны на предыдущих этапах жизненного цикла, с целью устранения расхождений до завершения этапа Внедрения; ◦ проводить независимую оценку новой или измененной услуги с целью построения перечня рисков, их категорирования и минимизации/устранения до завершения этапа Внедрения; ◦ использовать перечень рисков для тестирования; ◦ предоставить инструменты поддержки и диагностики, которые в случае возникновения проблем на этапе эксплуатации или тестирования позволят быстро найти и устранить проблему; ◦ обеспечить обмен информацией между Внедрением и Эксплуатацией с целью уменьшения времени диагностики и решения проблем; ◦ фиксировать известные ошибки и устранять инциденты в соответствии с их приоритетами; ◦ проактивный анализ основных причин повторяющихся и критичных инцидентов; ◦ классификация, измерение и документирование количества проблем и инцидентов в рамках каждого релиза и их негативного влияния с целью выявления возможностей по устранению ошибок; ◦ сравнивать количество и степень негативного влияния проблем и инцидентов между различными развертываниями с целью идентификации улучшений и разрешения основных проблем; ◦ информировать Управление инцидентами и Управление проблемами обо всех исправлениях и проблемах в рамках Внедрения. Планирование Внедрения. Управление изменениями, активами и конфигурациями в рамках Внедрения Рассмотрим процессы, которые составляют основу этапа Внедрения услуг. Процессы, деятельности в их рамках и взаимосвязи показаны на рис. 8.1. Рис. 8.1.  Процессы в рамках Внедрения Некоторые из представленных процессов выходят за рамки этапа Внедрения. Тем не менее, они рассматриваются в публикации "ITILv3. Service Transaction", так как лежат в основе Внедрения. Далее мы рассмотрим цели, охват, деятельности и другие параметры и составляющие процессов, представленным на рис. 8.1. 8.1. Планирование и поддержка Внедрения Основные цели Планирования и поддержки Внедрения: 1. планирование ресурсов и мощностей, необходимых для комплектования, сборки, тестирования, публикации, развертывания и вывода новых или измененных услуг в промышленную эксплуатацию; 2. предоставление поддержки для персонала в рамках Внедрения; 3. планирование изменений, необходимых для эффективного управления активами заказчиков, активами услуг и конфигурациями; 4. ведение отчетности обо всех проблемах, рисках и расхождениях перед заинтересованными сторонами и теми, кто ответственен за принятие решений; 5. координация проектов, поставщиков и контрактов, поддерживающих услуги. Планирование и поддержка Внедрения включает в себя: 1. учет операционных требований и требований проектирования в планах Внедрения; 2. управление деятельностями в рамках Внедрения; 3. управление процессами, рисками и расхождениями в рамках Внедрения; 4. качественный пересмотр планов Внедрения, развертывания и релиза услуг; 5. взаимодействие с заказчиками, пользователями и другими заинтересованными сторонами в вопросах, касающихся внедрения; 6. мониторинг и улучшение производительности Внедрения как процесса. Внедрение требует внимательного подхода и последовательных действий. Первое, что необходимо определить - Стратегия Внедрения. Она определяет общий подход организации к внедрению и должна рассматривать следующее: • цели Внедрения; • контекст внедрения (заказчики, договора и т.п.); • охват - то, что входит и не входит в рамки Внедрения; • применяемые стандарты, соглашения, требования регуляторов и контрактов; • организации и инвесторы, вовлеченные во Внедрение; • структура Внедрения: ▪ применяемые политики, процессы и практики; ▪ роли и ответственности; ▪ распределение ресурсов в рамках Внедрения; ▪ формирование требований к подготовке и обучению; ▪ механизм авторизации для доступа к релизам и изменениям; ▪ использование накопленного опыта, практики и данных; ▪ распределенные ресурсы и услуги, поддерживающие Внедрение; • критерии успеха для каждой стадии Внедрения, а также остановки или перезапуска деятельностей в рамках Внедрения; • определение требований и содержания новой или измененной услуги в контексте Внедрения; • персонал - назначение на роли, обучение и т.п.; • подход к Внедрению: ◦ модель Внедрения; ◦ планы управления изменениями, активами, конфигурациями и знаниями; ◦ планирование затрат, ресурсов и оценочных работ; ◦ подготовка к Внедрению; ◦ оценка; ◦ комплектование, сборка, развертывание и ранняя поддержка релиза; ◦ контроль и управление проблемами, ошибками, инцидентами и т.п. ◦ мониторинг процессов и формирование отчетности; ◦ система измерения производительности услуг; ◦ ключевые показатели производительности и цели по улучшению. • выходы деятельностей в рамках Внедрения, в том числе документация. Второй стадией является подготовка к Внедрению. На этой стадии проверяются и собираются все входы процессов, наличие необходимых конфигураций и общая готовность к Внедрению. В частности, детально рассматривается проектная документация (SDP), поступившая с этапа Проектирования. Именно она во многом определяет Внедрение. Следующая стадия - планирование и координация Внедрения. План Внедрения описывает задачи и действия, необходимые для передачи релиза на тестирование или промышленную эксплуатацию. Одним из основных вопросов является распределение ресурсов для конкретных деятельностей в рамках Внедрения. Набор планов внедрения находится между Стратегией внедрения и планами низших уровней - планами релизов, сборки, тестирования и т.п. Далее необходимо обеспечить поддержку Внедрения. Сюда относятся вопросы взаимодействия со всеми заинтересованными лицами, мониторинга производительности услуг и обеспечение обратной связи с другими этапами жизненного цикла. Формирование отчетности о ходе процессов и доведение ее до руководства и заинтересованных лиц позволит сделать выводы о соответствии планам, стратегиям и стандартам, а также эффективности Внедрения в целом. Таким образом, основными выходами процесса Планирования и поддержки Внедрения являются Стратегия Внедрения и набор планов Внедрения. Ключевые показатели производительности процесса: • количество релизов, которые соответствуют согласованным требованиям заказчиков по затратам, качеству, охвату и временным рамкам; • уменьшение несоответствия между тем, что получается на практике, и тем, что планировалось; • увеличение удовлетворенности пользователей и заказчиков планами и коммуникациями, которые позволяют настраивать бизнес-деятельность в соответствии с планами Внедрения; • уменьшение количества рисков, вопросов и задержек, вызванных некорректным планированием. 8.2. Управление изменениями Изменения являются важной составляющей любого бизнеса. Они могут быть проактивными и реактивными. Проактивные направлены на улучшение бизнеса, например, уменьшение издержек или увеличение эффективности поддержки. Реактивные являются ответными действиями на возникающие обстоятельства. Чаще всего осуществление реактивных изменений связано с адаптацией бизнеса к изменяющимся обстоятельствам. Изменение может иметь различную трактовку в зависимости от контекста. Изменение услуг - добавление, модификация или удаление утвержденной, запланированной или поддерживаемой услуги или ее компонента и соответствующей документации. Управление изменениями охватывает изменения в основных активах услуг и конфигурационных единицах в течение всего жизненного цикла услуг. Управление изменениями необходимо по следующим причинам: 1. оптимизация рисков; 2. минимизация негативного влияния на бизнес со стороны ошибок и сбоев; 3. успешная реализация изменений с первой попытки. Основными целями Управления изменениями является обеспечение: • использования стандартных методов и процедур для быстрой и эффективной реализации изменений; • фиксации всех изменений в активах услуг и конфигурациях в Системе Управления конфигурациями (CMS); • оптимизации всех рисков для бизнеса. На рис. 8.2 представлен охват процесса Управления изменениями. Рис. 8.2.  Охват Управления изменениями Стратегические изменения поступают с этапа Построения стратегии или от процессов управления бизнес-отношениями. Тактические изменения услуг поступают от этапа Проектирования, Непрерывного улучшения услуг и от процессов управления на уровне услуг. Корректирующие изменения, исправление ошибок в существующих услугах - от этапа Эксплуатации. Управление изменениями представляет ценность для бизнеса тем, что: 1. категорирует цели изменений бизнеса и заказчиков и помогает их осуществить; 2. реализует изменения, которые соответствуют потребностям заказчиков, одновременно с оптимизацией затрат; 3. старается выполнять требования закона, контрактов, руководства и регуляторов; 4. уменьшает количество неудавшихся изменений и, соответственно, количество сбоев, остановок и простоев услуг; 5. осуществляет изменения в установленном бизнесом временном интервале; 6. следит за изменениями на всем жизненном цикле услуг; 7. старается обеспечить лучшие показатели в аспектах качества, времени и затрат; 8. оценивает риски, сопутствующие внедрению; 9. помогает увеличить продуктивность работы персонала тем, что минимизирует нарушения и сбои, а, следовательно, улучшает доступность услуг; 10. уменьшает Среднее время восстановления услуг (MTRS) посредством быстрой и успешной реализации изменений; 11. сотрудничает с процессом изменения бизнеса для выявления возможностей улучшения бизнеса. Хорошо структурированные и запланированные изменения помогают бизнесу сократить издержки и повысить эффективность. Модель процесса изменения должна включать следующее: 1. шаги, которые должны быть предприняты для реализации изменения, в том числе разрешение проблем и непредвиденных событий; 2. хронологический порядок шагов; 3. ответственности и распределение обязанностей; 4. границы, в том числе временные, каждой деятельности в рамках процесса; Ни одно изменение не должно осуществляться без четкого планирования действий в случае, если оно будет неудачным - "планирование исправления". В идеале должен быть некий план "backup", который позволит организации вернуться в состояние, предшествующее изменению. Только посредством оценки того, какие действия по исправлению возможны в конкретной ситуации, можно определить риски, соответствующие изменению. Деятельности в рамках Управления изменениями включают: 1. планирование и контроль изменений; 2. составление расписаний для изменений и релизов; 3. обеспечение коммуникации между всеми участниками и компонентами; 4. авторизация к изменениям (то есть разрешения доступа тем, кто уполномочен вносить изменения) и принятие решений относительно изменений; 5. формирование планов по исправлению, которые будут задействованы в случае неудачных изменений; 6. измерение и контроль; 7. формирование управленческой отчетности; 8. оценка влияния изменения; 9. непрерывное улучшение. Стандартные действия при реализации отдельных изменений: • создание Запроса на изменение(RFC); • пересмотр и проверка RFC, фильтрация изменений; • оценка и определение изменения: ◦ установить уровень управления изменением; ◦ определить участников процесса; ◦ оценить мотивацию бизнеса, издержки, риски и выгоды, связанные с изменением; ◦ запросить независимую оценку изменения. • утверждение изменения (в том числе определение механизмов авторизации к нему); • формирование планов обновлений; • координация реализации изменения; • обзор и завершение изменения. На рис. 8.3 показан процесс реализации стандартного изменения. Рис. 8.3.  Процесс реализации стандартного изменения Рассмотрим подробнее действия в рамках реализации стандартного изменения. Запрос на изменение создается инициатором, в качестве которого может выступать отдельный человек или группа людей. Если требуется значительное изменение, может потребоваться Предложение изменения (Change Proposal). Предложение изменения должно содержать в себе детальную информацию об изменении, обоснование его необходимости (в том числе экономическое). Все полученные запросы на изменения должны быть зарегистрированы, в терминологии ITIL у каждого изменения должна быть запись. Запись об изменении (Change Record) - запись, содержащая детальную информацию об изменении. Каждая запись об изменении документирует жизненный цикл одного изменения. Запись об изменении создается для каждого полученного Запроса на изменение, даже если он впоследствии отклонен (отвергнут). Запись об изменении должна содержать информацию о конфигурационных единицах, которые затрагивает данное изменение. Записи об изменениях хранятся в Системе управления конфигурациями. Формат записи определяется на этапах планирования и проектирования. Информация, которую содержит запись об изменении, зависит от множества факторов: модель процесса реализации изменения, категория изменения и т.п. В рамках пересмотра RFC Управление изменениями рассматривает каждое изменение и отфильтровывает непрактичные, некорректно обоснованные и т.п. изменения. Для того чтобы оценить изменение ITIL предлагает ответить на 7 вопросов: 1. кто инициировал изменение? 2. какова причина изменения? 3. какой результат ждут от реализации изменения? 4. какие риски связаны с изменением? 5. какие ресурсы необходимы для реализации изменения? 6. кто ответственен за реализацию изменения? 7. какие связи изменение имеет с другими изменениями? В рамках оценки изменения необходимо определить следующее: • влияние, которое окажет изменение на операционную деятельность бизнеса; • влияние, которое окажет изменение на инфраструктуру и услуги заказчика; • влияние на другие услуги, которые используют ту же инфраструктуру; • влияние на инфраструктуры, не связанные с IT (например, транспортную, систему безопасности и т.п.); • что будет, если не реализовать изменение; • ресурсы, необходимые для реализации изменения - затраты, персонал, время и новые элементы инфраструктуры; • текущий график изменений и ожидаемый простой услуги. График изменений (Change Schedule) - документ, в котором перечислены все утвержденные изменения и их плановые сроки внедрения. Ожидаемый простой услуги (Projected Service Outage или PSO) - документ, определяющий влияние спланированных изменений, деятельности по обслуживанию и планов испытаний на согласованный уровень услуг; • дополнительные ресурсы, которые будут необходимы в случае реализации изменения; • влияние на план обеспечения непрерывности, план распределения мощностей, план обеспечения безопасности и т.п. При оценке важно сфокусироваться на факторах, которые могут навредить бизнесу, препятствовать предоставлению услуг надлежащего качества или негативно влиять на цели и политики организации. Для категорирования рисков многие организации используют таблицы, аналогичные табл. 8.1. Таблица 8.1. - Таблица для категорирования рисков Влияние изменения Категория влияния изменения/рисков Высокое влияние Низкая вероятность Категория риска: 2 Высокое влияние Высокая вероятность Категория риска: 1 Низкое влияние Низкая вероятность Категория риска:4 Низкое влияние Высокая вероятность Категория риска: 3 Вероятность На основании оценки влияния, рисков и выгоды для бизнеса от реализации изменения, менеджмент должен принять решение об утверждении изменения. Если в организации запланировано много изменений, необходимо провести их категорирование. Это позволит установить порядок реализации изменений - наиболее критичные должны выполняться в первую очередь. Категории изменения определяются из двух факторов: • выгода для бизнеса в случае успешной реализации изменения; • издержки и нарушения, которые возникнут, если изменение не будет реализовано. Аккуратное и детальное планирование изменений позволит исключить все неясности в процессе реализации изменения. При планировании рекомендуется ориентироваться на расписание бизнеса, а не IT, дабы не планировать изменения на время, критичное для бизнеса. На этом этапе формируется график изменений и ожидаемый простой услуги (см. выше). Следующим этапом является утверждение изменения уполномоченными лицами. Это может быть один человек или группа людей. Уровень руководства для отдельных изменений определяется исходя из их масштаба, влияния, рисков, стоимости и т.п. Утвержденные RFC поступают на реализацию. При этом процесс Управления изменениями следит за тем, чтобы все изменения осуществлялись согласно расписанию. Как уже отмечалось выше, для каждого изменения должен быть план исправления - действия, которые будут предприняты, если что-то пойдет не так и изменение не получится. При этом в документации к изменению должны быть определены роли и ответственности для тех, кто может инициировать эти планы. Отчет о реализации изменения должен показать, достигло ли изменение поставленных целей. Отчет предоставляется персоналу, ответственному за управление изменениями и всем заинтересованным лицам (в случае значительных изменений). Отчет также должен содержать все проблемы и инциденты, возникшие в процессе реализации изменения. После определенного промежутка времени Управление изменениями должно проводить обзор новой или измененной услуги с целью убедиться, что: • изменение достигло своих целей и принесло ожидаемый эффект; • пользователи, заказчики и другие заинтересованные лица удовлетворены результатами (в том числе определить неудовлетворенность, если она есть); • нет непредвиденных или нежелательных побочных эффектов в функциональности, уровнях услуг, качестве и т.п.; • для внедрения изменения понадобилось столько ресурсов, сколько планировалось; • планы релиза и развертывания были корректно реализованы; • изменение реализовано в заданных рамках времени и затрат; • план по исправлению работает корректно (опционально). В контексте Управления изменениями вводится термин Комитет по изменениям. Комитет по изменениям (Change Advisory Board или CAB) - группа людей, консультирующих менеджера по изменениям при выполнении им оценки соответствия, приоритезации и планирования изменений. Этот комитет обычно формируется из представителей всех заинтересованных сторон - поставщика услуг, бизнеса и третьих сторон, таких как прочие поставщики. CAB принимает решения о принятии изменений, требующих утверждения высокого уровня. При возникновении экстренных ситуаций иногда бывает недостаточно времени для того, чтобы получить одобрение всех членов CAB. Для таких случаев рекомендуется создавать Комитет по срочным изменениям. Комитет по срочным изменениям (Emergency Change Advisory Board или ECAB) -группа людей в составе Комитета по изменениям, которые принимают решения по Срочным изменениям с высоким влиянием. Необходимость участия в ECAB может быть выявлена непосредственно при созыве (организации) совещания и определяется исходя из сути Срочного изменения. В рамках Управления изменениями должно быть специализировано, как будет определяться состав CAB и ECAB в той или иной ситуации. Состав CAB должен быть гибким, чтобы обеспечить представление интересов бизнеса в процессе предложения значительных изменений. Состав ECAB должен быть способен принимать необходимые решения в случае непредвиденных обстоятельств. Запросы на изменение могут поступать со всех этапов жизненного цикла услуг, а также от других организаций, в частности, от поставщиков и заказчиков. RFC от Построения стратегии направлены на достижение целей по минимизации рисков и затрат. Например: • изменения в соответствии с законом и требованиями регуляторов; • организационные изменения; • изменения политик и стандартов; • изменения после анализа деятельности (бизнеса, заказчиков, пользователей); • добавление новой услуги на рынок; • обновление Портфеля услуг, портфеля заказчиков или портфеля контрактов; • изменение модели обеспечения; • инновационные технологии. Операционные изменения поступают, как правило, от пользователей. При этом важно понимать различные типы запросов. Это может быть, например, запрос на доступ или смену пароля. Если на этапе Непрерывного улучшения услуг принято решение о том, как может быть улучшена услуга, оно должно быть также оформлено в виде Запроса на изменение, а затем передано Управлению изменениями. Входами процесса Управления изменениями являются: • Политики и стратегии изменений и релизов; • Запросы на изменения; • Предложение изменения; • Планы изменения, внедрения, релиза, развертывания, тестирования, оценки и исправления; • График изменений и Ожидаемый простой услуги(PSO); • активы и конфигурационные единицы; • результаты и отчеты тестирования/оценки. Выходами процесса Управления изменениями являются: • отклоненные RFC; • утвержденные RFC; • изменения услуг и инфраструктуры - результат утвержденных RFC; • новые, измененные или распределенные активы или конфигурационные единицы; • график изменений; • пересмотренный Ожидаемый простой услуги(PSO); • утвержденные планы изменений; • решения и действия по реализации изменений; • документация и записи изменений; • отчеты Управления изменениями. Ключевые показатели производительности для Управления изменениями должны быть связаны с целями бизнеса, в частности, отражать сокращение издержек, увеличение доступности и надежности услуг, которые стали возможными в результате реализованных изменений. Такими показателями могут быть: • количество реализованных изменений, которые смогли удовлетворить согласованные требования заказчиков в качестве/издержках/времени; • выгода изменений - сравнение "ценность сделанных улучшений"+"предотвращенное негативное влияние" и стоимости реализации изменений; • уменьшение количества сбоев услуг, дефектов и дополнительных работ; • уменьшение количества неутвержденных изменений; • уменьшение количества невыполненных запросов на изменение; • уменьшение количества незапланированных изменений и экстренных исправлений; • процент успешных изменений - отношение изменений, признанных успешными, к общему количеству утвержденных запросов на изменение; • уменьшение количества изменений, в рамках которых есть работы по исправлению; • уменьшение количества неудавшихся изменений; • уменьшение количества инцидентов, связанных с изменениями; • и т.п. 8.3. Управление активами и конфигурациями Управление активами и конфигурациями (Service Asset and Configuration Management или SACM) - процесс, ответственный за Управление конфигурациями и Управление активами. Эффективность деятельности любой организации зависит от того, насколько хорошо она управляет своими активами. Именно работа с активами приносит организации прибыль. Управление активами ответственно за управление активами с целью поддержки других процессов Управления услугами. Целью SACM является определение и контроль компонентов услуг и конфигурационных единиц, а также предоставление достоверной информации о состоянии услуг и инфраструктур. Процесс фактически осуществляет инвентаризацию активов и назначение ответственных за их контроль. Управление конфигурациями отвечает за то, чтобы отдельные компоненты услуги, системы или продукта, были должным образом определены, снабжены всем необходимым и контролировались. Процесс также контролирует все изменения компонентов. Он предоставляет модель конфигураций со всеми связями между активами и конфигурациями. Объектом рассмотрения является Конфигурационная единица. Конфигурационная единица (Configuration Item или CI) - любой компонент, который нуждается в управлении для того, чтобы предоставлять услугу. Информация о каждой КЕ регистрируется в форме Записи о КЕ в Системе управления конфигурациями и поддерживается актуальной в течение всего жизненного цикла процессом Управления конфигурациями. КЕ находятся под контролем Управления изменениями. Типичными примерами КЕ являются услуги, оборудование, программное обеспечение, здания, люди и документы, такие как Процессная документация и Соглашения об уровне услуг (SLA). Для того чтобы управлять конфигурационными единицами, их нужно определить и классифицировать. ITIL рекомендует следующие категории: • СI жизненного цикла - бизнес-кейс, планы сервис-менеджмента, проектная документация, планы релизов, изменений и тестирования. Эти конфигурационные единицы предоставляют полную картину об услугах поставщика и их предоставлении, ожидаемых выгод от использования, затратах и сроках релиза. • CI услуг: ◦ возможности услуг - управление, организация, процессы, знания, люди; ◦ ресурсы услуг - капитал, системы, приложения, информация, данные, инфраструктуры и т.п.; ◦ модель услуг; ◦ пакет услуг; ◦ пакет релизов; ◦ критерии приемки услуг. • CI организации. Некоторая документация определяет характеристики CI, некоторая сама является CI и требует контроля, например, стратегия бизнеса или политика организации; • внутренние СI - материальные и нематериальные активы, которые необходимы для предоставления и управления услугами; • внешние CI - требования заказчиков, соглашения, релизы поставщиков и внешние услуги; • CI интерфейсов - активы, необходимые для предоставления услуг "от начала до конца" в рамках Интерфейса поставщика услуг. Интерфейс поставщика услуг (Service Provider Interface или SPI) - интерфейс между поставщиком услуг и пользователем, заказчиком, бизнес-процессом, или поставщиком. Анализ интерфейсов поставщика услуг помогает координировать сквозное управление услугами. Для управления совокупностью активов Управление активами и конфигурациями ведет Систему управления конфигурациями. Система управления конфигурациями (Configuration Management System или CMS) - набор инструментов и баз данных, которые используются для управления данными о конфигурациях поставщиком услуг. CMS также содержит информацию об инцидентах, проблемах, известных ошибках, изменениях и релизах; и может содержать данные о сотрудниках, поставщиках, местоположениях, бизнес-единицах, заказчиках и пользователях. CMS включает в себя инструменты для сбора, хранения, управления, обновления и представления информации обо всех конфигурационных единицах и их взаимоотношениях. Деятельности в рамках Управления активами и конфигурациями показаны на рис. 8.4. Рис. 8.4.  Деятельности в рамках Управления активами и конфигурациям Рассмотрим подробнее деятельности, представленные на рис. 8.4. Управление и планирование Не существует единого шаблона для осуществления SACM. Менеджеры каждой организации устанавливают уровень Управления конфигурациями, приемлемый для конкретного случая и то, как его можно достичь. Это отображается в Плане управления конфигурациями. Пример содержания Плана управления активами и конфигурациями. Контекст и цель. Охват: • применяемые услуги; • среда и инфраструктура: • географическое месторасположение. Требования: • требования стратегии и политик; • требования бизнеса, Управления услугами и контрактов; • совокупность требований к подотчетности и трассируемости; • требования Системы управления конфигурациями. Применяемые политики и стандарты: • политики; • индустриальные стандарты; • внутренние стандарты, относящиеся к Управлению конфигурациями, например, стандарты к оборудованию. Организация Управлением конфигурациями: • роли и ответственности; • комитеты для контроля изменений и конфигураций; • авторизация. Система и инструменты Управления активами и конфигурациями. Процессы и процедуры в рамках Управления активами и конфигурациями, например: • идентификация конфигураций; • управление версиями; • управление интерфейсами; • управление поставщиками; • управление изменениями конфигураций; • релиз и развертывание; • управление сборкой; • управление снабжением; • управление CMS. Ссылка на План реализации Управление и контроль необходимых связей и интерфейсов, в частности, с финансовым управлением активами и поставщиками. Идентификация конфигураций Для идентификации конфигураций важно: • определить, как будут категорироваться активы и конфигурационные единицы; • определить подход к идентификации и наименованию всех активов и конфигурационных единиц; • определить роли и ответственности для владельцев конфигурационных единиц отдельных типов в рамках этапов жизненного цикла, например, владелец услуги в процессе релиза. Деятельность в рамках идентификации конфигураций включает в себя: • определение и документирование критериев выбора конфигурационных единиц и составляющих их компонентов; • выбор конфигурационных единиц и их компонентов на основе установленных критериев; • назначение уникальных идентификаторов для выбранных конфигурационных единиц; • определение атрибутов для каждой конфигурационной единицы; • определение для каждой конфигурационной единицы момента, когда она поступает в Управление конфигурациями; • определение владельца, ответственного за каждую конфигурационную единицу. Модель конфигураций должна включать в себя связи и позицию каждой конфигурационной единицы. Важной частью Управления конфигурацией является определение уровня контроля для каждой конфигурационной единицы. Для этого применяется иерархический подход, так как каждая CI может являться частью другой CI или группы CI. Например, база данных может использоваться многими приложениями. Конфигурационные единицы нижних уровней не подвержены детальному контролю и аудиту. Например, клавиатуры, используемые в организации, могут послужить примером CI нижнего уровня. Важно отметить, что в зависимости от конкретной организации, критерии выбора CI нижнего уровня отличаются. Например, в здании ООН работает множество людей, говорящих на разных языках. Для их удобства используются разные клавиатуры - с английской, русской, итальянской и другими раскладками. Следовательно, для ООН информация о клавиатурах является относительно критичной и клавиатура как CI не находится на нижнем уровне иерархии. Всем конфигурационным единицам необходимо назначить имена, состоящие из идентификатора и версии. Имена должны быть уникальными. Помимо этого все физическое оборудование должно иметь бирки, по которым их можно будет легко идентифицировать. Атрибуты конфигурационных единиц описывают характеристики, значимые в рамках SACM. В базе данных должны содержаться атрибуты каждой конфигурационной единицы. ITIL выделяет следующие стандартные атрибуты: • уникальный идентификатор; • тип CI; • имя/описание; • версия; • расположение; • дата поставки; • детали лицензии ( в частности, дата ее истечения); • владелец/куратор; • статус; • поставщик/источник; • документация; • данные истории, например, аудиторские отчеты; • тип связей; • соответствующий SLA. Чаще всего характеристики CI содержатся в документации к ней. Связи конфигурационных единиц отражают то, как они взаимодействуют друг с другом в процессе предоставления услуг. Информация о связях хранится в CMS. Основные связи между CI: • CI является частью другой CI. Например, сервер является частью инфраструктуры сайта. Это отношение "родитель-ребенок"; • CI соединен с другим CI. Например, персональный компьютер соединен с локальной сетью; • CI использует другой CI. Например, программа использует модуль другой программы; • CI установлена на другую CI, например, Windows Excel на персональный компьютер. CI может иметь множество связей. Например, быть частью другой CI и одновременно использоваться другими CI. Контроль конфигураций Контроль конфигураций предоставляет механизмы контроля для конфигураций. CI не может быть перемещена, изменена, удалена без соответствующего контроля. Процедуры и политики контроля включают в себя: • лицензионный контроль - проверяет количество людей, которые используют лицензионный продукт, следит за тем, чтобы в организации не использовались нелицензионные продукты, следит за сроками истечения лицензий и т.п.; • управление изменениями; • контроль версий активов, программного и аппаратного обеспечения, релизов, сборок и т.п.; • контроль активов - возможности, место хранения, CMS; • контроль сборки с использованием документации от CMS; • поддержка и миграция электронных данных и информации; • формирование базы активов и конфигурационных единиц перед релизом; • контроль развертывания; • инсталляция; • управление целостностью Библиотеки эталонного ПО. Библиотека эталонного ПО (Definitive Media Library (DML) - одно или несколько защищенных хранилищ, в которых находятся определенные и авторизованные версии всех конфигурационных единиц, относящиеся к программному обеспечению. DML также может содержать CI, ассоциированные с ПО, такие как лицензии и документация. DML является логически единым хранилищем, даже если физически места хранения распределены. Все программное обеспечение в DML находится под контролем Управления изменениями и Управления релизами, должно быть зарегистрировано в Системе управления конфигурациями. В релизе может быть использовано только программное обеспечение из DML. Механизмы контроля должны быть спроектированы и встроены в новую или измененную услугу на ранних этапах ее развертывания. Учет статусов Каждая CI имеет ряд дискретных статусов в рамках своего жизненного цикла. Значимость каждого статуса определяется использованием CI в его рамках. Выделяют следующие статусы: • разработка или проектирование - CI находится на этапе проектирования и пока ее нельзя использовать; • утверждена - CI утверждена, и могут проводиться дальнейшие работы; • отозвана - CI больше не используется. Необходимо четко определить, как CI будет переходить из одного статуса в другой. Пример жизненного цикла приложения на рис. 8.5. Рис. 8.5.  Пример жизненного цикла конфигурационной единицы Учет статусов обеспечивает корректность и актуальность записей о конфигурационных единицах, активах и их состояниях. Стандартные деятельности в рамках Учета состояний: • управление записями о конфигурациях в процессе жизненного цикла; • управление записью, восстановлением и объединением статусов с целью обеспечения корректности, безопасности, своевременности и целостности; • обеспечение доступности информации о статусах в рамках Управления конфигурациями; • запись всех изменений в CI. Запись о конфигурации создается в процессе идентификации и контроля CI, рассмотренных нами выше. Она обеспечивает прозрачность и трассируемость CI для всех процессов. Стандартная запись содержит следующее: • информация о конфигурации - идентификационный номер, версия, статус, история изменений и т.п.); • конфигурация услуги или продукта - статус проектирования или сборки; • статус релиза обновления для конфигурации; • изменения, которые осуществлены или осуществляются; • сбор результатов тестирования качества. Проверки Включает в себя набор следующих проверок: • соответствие документации и актуального состояния CI; • физическое наличие CI в организации, функциональные характеристики; • документации для релиза до его осуществления. Только авторизованные и корректные CI должны использоваться для поддержки услуг. Если в рамках проверок выявлены нарушения, они должны быть немедленно устранены, а результаты проверок отображены в соответствующих отчетах. Как и любой другой процесс, SACM имеет свои ключевые показатели производительности. Применяются следующие метрики: • процентное улучшение в управлении расписаниями в рамках жизненного цикла активов; • ускоренная идентификация активов, вызвавших сбои в работе услуг; • уменьшение влияния инцидентов и ошибок на CI; • процент лицензий, которые используются, к общему количеству купленных ( в идеале 100%); • увеличение качества информации о CI в CSM; • уменьшение использования нелицензионного ПО; • и т.п. Информацию, формируемую в рамках SACM, используют все процессы в рамках жизненного цикла услуг. Управление релизами и развертыванием в рамках Внедрения услуг Управление релизами и развертыванием отвечает за предоставление и тестирование возможностей для предоставления услуг, определенных на этапе Проектирования. Основные цели Управления релизами и развертыванием: 1. формирование и согласование планов релизов и развертывания с заказчиками и инвесторами; 2. гарантия того, что каждый пакет для релиза состоит из набора связанных и совместимых компонентов; 3. осуществление управления релизом и его компонентами в рамках процессов Внедрения; 4. гарантия того, что все пакеты для релизов могут быть протестированы, отслежены, проверены, установлены или устранены (при необходимости); 5. гарантия того, что все изменения управляются в рамках деятельностей по управлению релизами и развертыванием; 6. ведение отчетов и управление рисками, проблемами, расхождениями, связанными с новой или измененной услугой. Осуществление корректирующих действий при необходимости; 7. обеспечение доступа к информации для заказчиков и инвесторов, чтобы они могли эффективно использовать новую или измененную услугу; 8. обеспечение доступа к информации для операционного персонала, чтобы он мог предоставлять, поддерживать и управлять услугой. Управление релизами и развертыванием отвечает за выпуск релизов и их эффективное использование заказчиками. Единица релиза (Release Unit) - компоненты услуги, которые обычно компонуются вместе и выпускаются в рамках одного релиза. Единица релиза обычно включает в себя компоненты, необходимые для выполнения какой-либо полезной функции. Например, Единицей релиза может быть настольный компьютер, включающий в себя программное, аппаратное обеспечение, лицензии, документацию и т.п. Другим примером Единицы релиза может служить целое приложение для расчета зарплаты, включая процедуры операционного управления IT и тренинги пользователей. Важно определить подходящий уровень Единицы релиза для каждого актива и компонента. Необходимо учитывать следующие факторы: • простота и количество изменений, необходимых для релиза и развертывания; • количество ресурсов и времени, необходимое для сборки, тестирования и развертывания; • сложность взаимосвязей между единицей и остальными услугами и компонентами; • хранение, доступное в рамках сборки, тестирования, распространения и эксплуатации. Подход преобразования новой или измененной услуги определяется в рамках этапа Проектирования. Существует две опции внедрения: 1. "большой взрыв" - новая или измененная услуга развертывается сразу для всех пользователей в рамках одной операции; 2. пофазовый подход - услуга развертывается поэтапно. Сначала одной части пользователей, затем остальным. На рис. 9.1 представлено применение двух подходов. Рис. 9.1.  Два подхода к развертыванию услуг 1. Релиз 1 - начальная установка на три рабочие станции (1-3). Две другие станции добавляются в тот же период времени (4-5); 2. Релиз 2 - использование подхода "большой взрыв" для развертывания. Релиз устанавливается сразу на пять рабочих станций (1-5). На другом шаге на две дополнительные станции (6-7); 3. Релиз 3 - пофазовый подход для развертывания. Сначала обновляется только три рабочие станции (1-3), затем оставшиеся четыре (4-7). Еще одна станция добавляется на следующем этапе (8). Пофазовый подход имеет следующие вариации: 1. порции услуги предоставляются для использования по фазам, но все пользователи будут подключены к ней одновременно; 2. каждый релиз развертывается постепенно в зависимости от количества конечных пользователей; 3. разные элементы услуги развертываются в рамках разных фаз; 4. комбинированный подход, применяющий все описанные выше. Пофазовый подход возможен только в том случае, если старая и обновленная услуги совместимы и могут работать одновременно. Рассмотрим последовательность действий в рамках Управления релизами и развертыванием. Для развертывания релиза необходимо разработать различные планы, в частности, Планы релизов и развертывания. Они должны определять: • охват и контекст релиза; • оценку рисков для релиза; • организации и отдельные лица, которых затронет релиз; • инвесторы, которые утвердили запрос на изменение; • команда, ответственная за релиз; • подход к взаимодействию с инвесторами и группами развертывания, который определяет: ◦ стратегию предоставления и развертывания; ◦ ресурсы для релиза и развертывания; ◦ количество изменений, которые могут быть осуществлены. В рамках Внедрения должны быть определены критерии, которые позволят установить успешность выполнения каждой стадии релиза и развертывания. Результат выполнения либо принимается - pass, либо отклоняется - fall. Отсюда критерии называются прием/отклонение (pass/fall) критерии. Пример, когда результат принимается: Все тесты завершены успешно; отчет по оценке и RFC для сборки и тестирования подписаны. Примеры, когда результаты отклоняются: • недостаток ресурсов для перехода на следующую стадию. Например, тестирование показало недостаточность финансовых средств для предоставления спроектированной услуги на стадии эксплуатации; • этап Эксплуатации услуг не может предоставить отдельные атрибуты услуг; • этап Проектирования услуг разработал проект, не соответствующий установленным стандартам, технологиям, требованиям регуляторов и т.п.: • услуга не может быть предоставлена в соответствии с ограничениями, наложенными на этапе Проектирования; • не выполняются критерии приемки услуги; • необходимые документы не подписаны; • SKMS и CSM не обновлены и содержат неактуальную информацию; • количество инцидентов, проблем и рисков выше, чем предполагалось изначально. Перед передачей услуги в промышленную эксплуатацию, необходимо совершить ряд действий по сборке и тестированию различных сред. Деятельность в рамках планирования сборки и тестирования заключается в: • формирование планов сборки исходя из проектной документации, спецификаций, требований к конфигурации оборудования; • формирование команд сопровождения, логистики и сборки, необходимых для поддержки сред; • тестирование сборки; • составление расписаний для тестирования и сборки; • назначение ролей, распределение ресурсов и ответственности для ключевых деятельностей; • согласование критериев приемки сборки. Среды, необходимые для релиза: • среда сборки - используется для сбора и комплектования пакета релиза; • единичная среда тестирования - используется для проверки функциональности, производительности, восстанавливаемости и полезности отдельных компонентов услуги; • комплект сред тестирования - используется для проверки функциональности, производительности, восстанавливаемости и полезности комплекта компонентов услуги; • среда интеграции - используется для сборки и интеграции компонентов услуги; • среда тестирования услуги - используется для тестирования всех аспектов объединенной архитектуры услуги; • среда тестирования релиза - используется для установки, сборки и тестирования пакета релиза в контролируемой среде; обычно совмещена со средой тестирования услуги. • среда тестирования готовности к эксплуатации - для тестирования возможностей услуги и ее компонентов перед передачей в промышленную эксплуатацию; • среда, симулирующая бизнес-среду; • среда, симулирующая Управление услугами; • среда для обучения; • среда для пилотирования; • среда для резервного копирования и восстановления. Для тестирования услуги на маленькой части пользователей используются пилоты. Пилот (Pilot) - ограниченное развертывание услуги, релиза или процесса в среде промышленной эксплуатации. Пилот используется для сокращения рисков и получения обратной связи, а также приемки от пользователей. При этом важно определить оптимальный охват пилота. Если он будет слишком маленьким, будет некорректно отображена функциональность услуги и не выявятся многие ошибки. Для пилотирования также должны формироваться планы. Планирование сборки пакета релизов содержит следующие процедуры: • проверка критериев входа/выхода; • взаимодействие с инвесторами: ◦ управление контрактами и их деталями; ◦ доведение до инвесторов информации о предлагаемых изменениях, выгоде, которую они могут принести и сопутствующих затратах и рисках • обучение персонала и передача знаний; • установление услуг и активов в виде имеющихся контрактов; • согласование графиков; • разработка механизмов и инструментов для: ◦ сборки, тиражирования, продвижения, распространения, контроля, инсталляции и активации релизов; ◦ управления лицензиями и авторскими правами. • настройка систем и обучение пользователей для работы с новой или измененной услугой; • разработка возможностей и ресурсов для сервис-менеджмента; • оценка готовности целевой группы к использованию релиза; • определение и согласование критериев для выхода. В рамках составления планов развертывания необходимо ответить на следующие вопросы: • для кого предназначено развертывание? • кто будет пользователями? • есть ли какие-то особенности месторасположения? (например, какие-то дополнительные выходные в зависимости от региона) • где пользователи? (например, есть ли удаленные пользователи или все пользователи будут работать в одном месте) • кто еще должен быть подготовлен к релизу? (например, нужно ли дополнительное обучение персонала сервис-деска) • когда необходимо завершить развертывание? • почему необходимо развертывание? (например, чтобы исправить какую-то проблему или увеличить функциональность) • какие факторы успеха и критерии выхода? (как узнать, что развертывание прошло успешно и может быть завершено) • каковы текущие возможности поставщика услуг? Далее разрабатываются Планы снабжения и предоставления. Они определяют следующее: • как и когда релиз и его компоненты будут предоставляться? • какие имеются команды сопровождения, и что будет в случае задержки? • как отследить прогресс в предоставлении и необходимость его завершения? • есть ли возможность защищенного хранения, если потребуется? Прежде чем добавлять какие-то действия в планы развертывания, необходимо осуществить финансовое планирование. Оно рассматривает вопросы выделения средств для обеспечения деятельностей, покупки необходимого оборудования и лицензий, имеющиеся контракты и обязательства. После того, как детальные планы для каждой деятельности в рамках Управления релизами и развертыванием составлены, наступает этап подготовки к сборке, тестированию и развертыванию. На этом этапе происходит оценка рисков, возможных проблем и несоответствий в проектной документации. Оценка проверяет, принесет ли изменение желаемые результаты. Формируется отчет, в котором содержатся рекомендации об утверждении изменения или его отклонении. Если изменение утверждено, наступает этап сборки и тестирования. Ключевые аспекты, которыми необходимо управлять в рамках этого этапа: • использование сред сборки и тестирования; • стандартизация и интеграция; • управление конфигурациями: • в ходе деятельностей по сборке и тестированию - контроль версий, управление базовым состоянием, контроль входов и выходов этапа сборки и тестирования; • ведение отчетности, которая позволит осуществить сборку снова при возникновении необходимости; • управление наглядностью тестирования - формирование отчетов по тестированию; • контроль доступа к физическим компонентам и технологиям; • проверка выполнения требований безопасности; • проверка деятельностей - все необходимые условия выполнены; • управление вопросами среды - кондиционирование, электропитание, физическое место, пожарная сигнализация и т.п. • проверка готовности релиза к передаче на следующую стадию; • передача релиза на следующую стадию. В ITIL вводится понятие "базовое состояние". Базовое состояние (Baseline) - зафиксированное состояние, используемое как ориентир (контрольная точка). Трактовка зависит от контекста. В контексте Внедрения базовое состояние может быть использовано для возврата инфраструктуры к исходной конфигурации в случае, если внедрение релиза оказалось неудачным. Информация о базовых состояниях конфигураций хранится в CMS. Для сборки релиза необходимо объединить множество компонентов, активов и продуктов от внешних и внутренних поставщиков. В этом большую роль играет документация - соглашения, контракты, лицензии и т.п. Деятельность по приобретению компонентов включает в себя: • взаимодействие с процессами снабжения для приобретения компонентов; • сбор: ◦ информации о новых и обновленных активах и конфигурационных единицах от SACM; ◦ квитанций и чеков; ◦ документации предоставления, релиза и изменения от поставщика. • проверка, мониторинг и ведение отчетности о качестве поступающих конфигурационных единиц и компонентов услуг; • обеспечение того, что наличие лицензии можно будет доказать при возникновении необходимости; • ответные действия в случае, если качество, полученное на практике, отличается от ожидаемого, и оценка влияния снижения качества на внедрение в целом; • обновление статусов конфигурационных единиц в SACM. После того, как все необходимое куплено, документация готова, можно приступить к сборке пакета релизов. При сборке релизов важно понимать, что продукт поступит скоро в промышленное производство, следовательно, использованные в рамках сборки процедуры должны быть повторимы в случае необходимости. Ключевые этапы деятельности сборки пакета релизов: • комплектование и интеграция компонентов релиза; • создание документации для сборки и релиза ▪ планы сборки, тестирования и инсталляции; ▪ детальное описание механизмов мониторинга и проверки качества релиза; ▪ детальное описание ответных действий в случае возникновения проблем; ▪ автоматические и ручные процедуры, необходимые для развертывания услуги в среде промышленной эксплуатации; ▪ процедуры по возвращению в исходное состояние в случае неудавшегося релиза; ▪ процедуры контроля лицензий. • инсталляция и проверка пакета релиза; • отправка уведомлений всем заинтересованным участникам о том, что пакет релиза готов для инсталляции и использования. Если тестирование пакета релизов прошло успешно, релиз и его составляющие попадают под контроль Управления конфигурациями. С этого момента все изменения в пакете релизов осуществляются через Управление изменениями. Критерии тестирования должны отражать условия, в которых услуга будет использоваться и предоставлять выгоду заказчикам. Тестирование релиза проверяет, что компоненты релиза могут корректно интегрироваться, а сам релиз можно инсталлировать в целевую среду. Тестирование операционной готовности проверяет, что услуга и поддерживающие ее инфраструктуры могут быть переданы в производство. Оно также предоставляет определенный уровень уверенности в том, что новая или измененная услуга будет соответствовать установленным требованиям. В рамках тестирования операционной готовности проводятся следующие тесты: • тестирование готовности к развертыванию - проверяет то, что процессы, процедуры и системы развертывания могут развертывать, устанавливать, назначать и списывать пакет релизов и соответствующую ему услугу в среде производства/развертывания; • тестирование Управление услугами - проверка того, что производительность услуги может быть измерена и проконтролирована в процессе промышленной эксплуатации; • тестирование группы эксплуатации - проверяет, что сервисные подразделения смогут управлять услугой в процессе промышленной эксплуатации; • тестирование уровня услуг - проверка соответствия новой или измененной услуги требованиям уровня услуг; • тестирование пользователей - проверка того, что пользователи имеют доступ к новой или изменой услуге и могут ее использовать; • тестирование интерфейса поставщика услуг - проверка того, что интерфейсы, поддерживающие услугу, функционируют; • тестирование развертывания - проверка того, что услуга корректно развернута для каждой целевой группы или среды. После проведения указанных выше тестов наступает заключительный этап тестирования - "репетиция услуги". Это метод тестирования, в котором создаются условия, максимально приближенные к условиям реальной эксплуатации. Он должен выявить ошибки и неработающие процессы, прежде чем они повлияют на бизнес в процессе промышленной эксплуатации. Проводится перед непосредственным развертыванием услуги. Как вариант может осуществляться в виде пилота - то есть на маленькой группе реальных пользователей услуги. После успешного тестирования или пилотирования можно приступить к развертыванию услуги. На начальном этапе составляются детальные планы развертывания, и производится оценка рисков. Планы должны быть утверждены, а Запросы на изменения авторизованы процессом Управления изменениями. Только после этого услуга готова к развертыванию. В рамках развертывания могут выполняться следующие действия: 1. перенос финансовых активов: ▪ любые изменения в финансовых соглашениях; ▪ покупка или перенос ежегодной поддержки; ▪ управление затратами, в том числе на системы управления услугой; ▪ новые цены на лицензии и обновления; ▪ годовые контракты на восстановление в случае сбоя с третьими сторонами; ▪ предоставление или перенос оборотного капитала; ▪ перенос прав на интеллектуальную собственность. 2. Перенос/переход бизнеса и организации 3. окончательное оформление организационной структуры, ролей и ответственностей; 4. установление связей между изменениями организации, ролей и ответственностей; 5. убедиться в том, что люди могут приспособиться к новым практикам; 6. убедиться в том, что люди понимают планы и процедуры обеспечения непрерывности. Сюда также входит найм квалифицированного персонала, способного реализовать развертывание. • развертывание процессов и материалов; • развертывание возможностей Управления услугами - новые процессы, инструменты и системы для персонала, ответственного за управление услугами. • перенос услуги: ◦ перед переносом пересматриваются риски, проблемы услуги и значения ее производительности; ◦ настройка аудита для услуги и конфигураций; ◦ внесение в Каталог услуг информации о новой или измененной услуге; ◦ уведомление инвесторов об изменении. • развертывание услуги - развертывание релиза, в том числе действия по распространению и установке услуги, поддерживающих услуг, приложений, инфраструктуры и функциональных возможностей. В этот этап входят следующие деятельности: ◦ распространение и развертывание услуги и ее компонентов в заданных границах времени; ◦ сборка, установка и настройка услуги и ее компонентов на работу с новой или преобразованной информацией; ◦ тестирование системы и услуг в рамках инсталляции, формирование отчетов об инсталляции и тестировании; ◦ фиксация всех проблем, сбоев, ошибок, инцидентов и расхождений с планами; ◦ корректирование всех расхождений, которые не выходят за рамки проектных ограничений. • Отзыв услуги - действия, предпринятые для того, чтобы релиз можно было отозвать в случае возникновения необходимости: ◦ удаление развернутых копий программного обеспечения и данных с аппаратного обеспечения; ◦ идентификация лицензий и других активов, которые могут быть отозваны; ◦ расположение оборудования в соответствии с политиками и процедурами; ◦ перемещение отозванных активов в защищенное хранилище при необходимости. Записи о действиях по отзыву, восстановлению и расположению должны управляться и использоваться для обновления другой информации, например, об имеющихся в организации лицензиях. • удаление избыточных активов. Если услуга отозвана, необходимо пересмотреть использование активов. Активы отозванной услуги могут быть использованы для других услуг либо извлечены из обращения, что приведет к снижению издержек. • верификация развертывания. После того, как деятельности в рамках развертывания завершены, необходимо убедиться, что пользователи, группа эксплуатации и инвесторы готовы к использованию услуги. Это включает в себя выполнение следующих действий: ◦ проверка того, что услуги, активы и ресурсы "на своих местах"; ◦ проверка того, что обновление документации и информации завершено; ◦ материалы для обучения и координации готовы для предоставления инвесторам, пользователям и группе эксплуатации; ◦ проверка того, что роли и ответственности распределены; ◦ персонал и другие ресурсы готовы для управления и использования услуги и ее компонентов в нормальных и экстренных условиях; ◦ участники имеют доступ к информации, необходимой для управления, поддержки и использования услуги; ◦ настроены механизмы измерения производительности услуги и поддерживающих ее ресурсов. • поддержка в начале эксплуатации (Early Life Support или ELP) - поддержка, предоставляемая в отношении новой или измененной услуги в течение некоторого времени непосредственно после того, как услуга была введена в эксплуатацию. Во время поддержки в начале эксплуатации поставщик услуг может пересматривать ключевые показатели производительности, уровни услуги и наблюдаемые пороговые значения, а также задействовать дополнительные ресурсы для Управления инцидентами и Управления проблемами. Пример деятельностей в рамках Поддержки в начале эксплуатации показан на рис. 9.2. Рис. 9.2.  Пример деятельностей в рамках Поддержки в начале эксплуатации В процессе ELP группа развертывания реализует улучшения и решает возникающие проблемы, то есть стабилизирует использование услуги. Также происходит обновление базы данных дополнительными данными диагностики, известными ошибками, наиболее часто задаваемыми вопросами и т.п. • обзор и завершение развертывания Обзор развертывания включает в себя следующие действия: ◦ организация опросов и исследований удовлетворенности пользователей, инвесторов и заказчиков новой или измененной услугой; ◦ выявить недостигнутые критерии качества; ◦ проверить завершенность всех необходимых действий, исправлений и изменений; ◦ пересмотреть незавершенные изменения и убедиться в том, что для них выделены финансовые средства и назначены ответственные исполнители; ◦ пересмотреть целевые показатели производительности и успешности; ◦ убедиться, что все проблемы, связанные с ресурсами, возможностями, мощностями и производительностью, решены до завершения развертывания; ◦ проверить то, что все проблемы, известные ошибки и обходные решения согласованы с инвесторами, заказчиками и пользователями. Обходное решение (Workaround) - уменьшение или устранение влияния инцидента или проблемы, для которых в текущий момент недоступно полное разрешение. Например, перезапуск отказавшей конфигурационной единицы. Обходные решения для проблем документируются в записях об известных ошибках. Обходные пути для инцидентов, которые не привязаны к записям о проблемах, документируются в записях об инцидентах. ◦ пересмотреть все риски и выявить те, которые влияют на эксплуатацию и поддержку услуги; ◦ проверить то, что избыточные активы извлечены из обращения; ◦ проверить готовность услуги к передаче от ELP в промышленную эксплуатацию. Обзоры, проводимые после завершения развертывания, контролируются процессом Управления изменениями. • обзор и завершение внедрения Перед тем, как завершить Внедрение полностью, необходимо предоставить формальный обзор Внедрения, включающий в себя: ◦ проверку того, что все деятельности в рамках Внедрения завершены, то есть информация и документация собраны, обновлены, защищены; ◦ проверку того, что применяются правильные и точные метрики. Обзор аккумулирует выходы всех процессов, процедур и деятельностей в рамках Внедрения. Успешное проведение оценки гарантирует то, что услуга передана на этап Эксплуатации. Входами процесса Управления релизами и развертыванием являются: • авторизованные Запросы на изменения; • Проектная документация; • пакет уровней услуг; • План обеспечения непрерывности бизнеса и IT; • Планы и стандарты сервис-менеджмента; • технологические стандарты и каталоги снабжения; • приобретенные активы и компоненты с их документацией; • модели и планы сборки; • требования и спецификации сред для сборки, тестирования, пилотирования, развертывания, обучения и восстановления; • политика и проект релизов от этапа Проектирования; • модели релизов и развертывания; • критерии входа и выхода для каждой стадии развертывания и релиза. Выходами процесса Управления релизами и развертыванием являются: • План релиза и развертывания; • завершенные Запросы на изменения для деятельностей в рамках релиза и развертывания; • оповещение об услуге; • обновленный Каталог услуг с информацией о новой или измененной услуге; • новые протестированные возможности услуги и среды; • новая или измененная документация сервис-менеджмента; • пакет услуг, учитывающий требования бизнеса/заказчиков к услугам; • Пакет уровней услуг (SLP); • SLA, OLA и другие контракты; • модель услуг, описывающая структуру и динамику управления и использования услуг; • отчеты о новых или измененных услугах; • протестированные планы непрерывности; • полный и актуальный перечень конфигурационных единиц; • план мощностей соответствующий планам бизнеса; • подготовленный пакет релизов - для развертываний в будущем; • отчет о внедрении. Ключевые показатели производительности Управления релизами и развертыванием можно разделить на два класса: 1. Заказчики и бизнес: ◦ уменьшение отклонения значений производительности услуг от требуемых заказчиками и бизнесом; ◦ уменьшение количества инцидентов, связанных с услугами; ◦ увеличение удовлетворенности пользователей и заказчиков предоставленными услугами; ◦ уменьшение неудовлетворенности пользователей и заказчиков. 2. Поставщики услуг: ◦ уменьшение необходимых ресурсов и затрат для диагностирования и исправления инцидентов и проблем в рамках развертывания и производства; ◦ увеличение использования стандартизированного подхода к Внедрению, в том числе процессов, документации и стандартов; ◦ уменьшение несовпадений между информацией, предоставляемой проверками конфигураций, и реальной ситуацией.