ЭиП-334

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

Успешное проведение Управления Релизами зависит от входной информации, поступающей из других процессов ITIL, и от взаимодействия с этими процессами (рис.
1). Главными являются интерфейсы со следующими процессами.
Управление Конфигурациями
Управление Конфигурациями отвечает за регистрацию доступных версий программного и аппаратного обеспечения в базе данных CMDB в качестве Базисных Конфигураций. Программы, включаемые в Библиотеку DSL, и аппаратные средства для DHS регистрируются в CMDB с согласованным уровнем детализации. Мониторинг статуса, выполняемый Процессом Управления Конфигурациями, отражает статус каждой Конфигурационной Единицы, например, «В активном использовании». «В разработке», «В тестировании», «В запасе» или «В архиве».
Управление Изменениями
Деятельность по распространению (тиражированию) релизов контролируется Процессом Управления Изменениями. Кроме того, Управление Изменениями гарантирует, чтобы было проведено адекватное тестирование релизов. Управление Изменениями также принимает решение о количестве изменений, которые могут быть скомбинированы в одном релизе. Управление Изменениями определяет процедуры, обеспечивающие авторизацию изменений, включая анализ степени воздействия и анализ необходимых ресурсов. В большинстве случаев Руководитель Процесса Управления Релизами несет ответственность за внедрение программных и аппаратных изменений и он обычно участвует в работе Консультативного комитета по изменениям.
Управление Уровнем Услуг
ИТ‐сервис обычно включает в себя инфраструктурное аппаратное обеспечение вместе со стандартным или разработанным собственными силами программным обеспечением. Управление Релизами отвечает за ввод в работу программных и аппаратных средств и отслеживает соглашения о доступности программных средств, заключенные в рамках Процесса Управления Уровнем Услуг.
Виды деятельности
На рис. 2 показаны виды деятельности в рамках Процесса Управления Релизами и их связи с жизненным циклом изменения.

Виды деятельности
Выработка политики в отношении релизов и планирование Руководитель Процесса Управления Релизами разрабатывает политику в отношении релизов, определяя когда и каким образом производится конфигурирование релизов. Значительные релизы могут планироваться заранее, одновременно с присвоением номера версии, чтобы в определенные моменты времени можно было рассмотреть возможность внесения изменений. Руководитель Процесса Управления Релизами также определяет, на каком уровне Конфигурационные Единицы могут распространяться независимо друг от друга (релизные единицы). Это зависит от:
• Потенциального воздействия релиза на другие компоненты.
• Количества человеко‐часов и времени на компоновку и тестирование
раздельных изменений, в сравнении с усилиями, необходимыми для их объединения и одновременного внедрения.
• Трудности инсталляции на местах пользователей. Возможно, что инсталлировать полную программу легче благодаря наличию для этого стандартных методов.
• Сложности взаимосвязей между новым программным и аппаратным обеспечением и остальной частью ИТ‐инфраструктуры ‐ чем легче изолировать программные или аппаратные средства, тем легче их тестировать. Перед планированием релиза необходимо собрать информацию о жизненном цикле внедряемого продукта, а также обо всех подготовленных к сдаче в рамках данного релиза продуктах, описании соответствующих ИТ‐услуг и их уровней и данные об авторизации соответствующих Запросов на Изменения (RFC) и т. д. При планировании релиза рассматриваются следующие вопросы:
• координация содержания релиза;
• разработка графика ввода релиза;
• согласование графика, территориальных объектов, на которых произойдет распространение релиза, и организационных единиц;
• посещение объектов для определения реально используемых аппаратных и программных средств;
• разработка плана оповещения (коммуникаций);
• согласование ролей и ответственностей;
• получение подробных коммерческих предложений и переговоры с поставщиками о новых аппаратных и программных средствах, а также услугах по их инсталляции;
• разработка планов на случай возврата к исходному состоянию;
• разработка плана обеспечения качества релиза;
• планирование приемки релиза руководством и пользователями.
Результаты этой деятельности представляют собой часть плана проведения изменения и включают планы релиза, планы тестирования и критерии приемки.

Проектирование, компоновка и конфигурирование
Рекомендуется выработать стандартные процедуры проектирования, компоновки и конфигурирования релизов. Основой релизов могут быть наборы компонентов (Конфигурационных Единиц — CI), разработанные внутри организации или закупленные у третьей стороны и прошедшие этап конфигурирования. Руководства по инсталляции и конфигурированию релизов должны рассматриваться как часть релиза и в качестве Конфигурационных Единиц должны включаться в число объектов, находящихся под контролем Процессов Управления Изменениями и Управления Конфигурациями. Перед инсталляцией на месте рекомендуется настроить и протестировать все аппаратное и программное обеспечение в «лабораторных условиях». Компоненты программных и аппаратных средств необходимо тщательно конфигурировать и зарегистрировать, чтобы обеспечить возможность их многократного воспроизведения. Необходимо разработать рабочие инструкции таким образом, чтобы каждый раз воспроизводился один и тот же набор компонентов. Часто в резерве имеются стандартизированные аппаратные средства, которые используется только для компилирования или создания образов ПО. Для надежности желательно, чтобы эта часть процесса была автоматизирована. Необходимые для этого программные и аппаратные средства также попадают в сферу действия Процесса Управления Релизами. В среде разработки программ такая деятельность называется Управлением Компоновкой и входит в зону ответственности Управления Релизами.

План возврата к исходному состоянию
В плане возврата к исходному состоянию на уровне релиза в целом определяются действия, необходимые для восстановления услуг в случае сбоя во время внедрения (имплементации) релиза. Ответственность за разработку планов возврата несет Процесс Управления Изменениями, но Управление Релизами должно оказывать в этом помощь для обеспечения практической реализуемости этих планов. В частности, при внедрении пакетного релиза, объединяющего несколько Запросов на Изменения (RFC), может возникнуть необходимость координации различных планов возврата для этого релиза. Если возникает сбой Полного релиза или Дельта‐релиза, рекомендуется свернуть релиз полностью до Прежнего стабильного состояния. На случай невозможности полного свертывания релиза должны существовать Планы восстановления на случай чрезвычайных обстоятельств для возобновления предоставления услуг. Требования плана возврата к исходному состоянию, такие как создание резервных копий и обеспечение запасного сервера, рекомендуется выполнять заранее. В случаях, если внедрение может занять больше времени, чем предполагается, и если задержка может поставить под угрозу нормальное предоставление услуг, в план возврата должен включаться крайний срок, определяющий время приведения в действие плана возврата. Это требуется для своевременного возобновления услуг (например, не позднее 7:00 в понедельник). План возврата к исходному состоянию должен включаться в анализ рисков изменения и должен быть одобрен пользователями. Реальная компоновка релиза может включать компилирование и связывание программных модулей, или наполнение баз данных тестовыми данными, или такими данными, как таблицы почтовых индексов, налоговых ставок, часовых поясов и валютных курсов, а также информацией о пользователях. Часто это выполняется автоматизированными инсталляционными скриптами, хранящимися в Библиотеке DSL вместе с планами возврата. Полные релизы должны отражаться в базе CMDB как Стандартные Конфигурации для облегчения конфигурирования в будущем. Планы тестирования должны включать тестирование и приемку по качеству программного и аппаратного обеспечения, процедур, инструкций по операционной деятельности и сценариев (скриптов) развертывания перед выходом релиза и, возможно, оценочные испытания после внедрения релиза. Должно также проводиться тестирование инсталляционных скриптов. Для этого требуется следующая информация:
• определение релиза;
• график ввода релиза;
• инструкции по конфигурированию и компоновке релиза;
• описание позиций, требующих приобретения или лицензирования, с
приложением графиков закупки;
• автоматизированные инсталляционные скрипты и планы тестирования;
• исходные копии кодов программ для включения в библиотеку DSL;
• планы возврата к исходному состоянию.

Планирование внедрения
Составленный на предыдущих этапах план теперь дополняется информацией о действиях по внедрению.
Планирование развертывания релиза включает:
• составление графика, а также перечня задач и требуемых людских ресурсов;
• составление перечня инсталлируемых и снимаемых с использования Конфигурационных Единиц, с указанием способа вывода из операционной среды;
• составление плана действий для каждого территориального объекта с учетом запаса времени на развертывание и часовых поясов, если речь идет о географически распределенных организациях;
• рассылку уведомлений о релизе и другие контакты с вовлеченными сторонами;
• составление планов закупки аппаратного и программного обеспечения;
• закупку, размещение на хранение, определение и регистрацию всех новых CI для данного релиза в базе CMDB;
• планирование встреч с руководством, управляющими подразделениями, персоналом по Управлению Изменениями и представителями пользователей.

Существует несколько способов осуществления развертывания:
• полное развертывание релиза ‐ подход «большого скачка»;
• поэтапное развертывание релиза, включающее несколько разновидностей:
- функциональное наращивание, когда все пользователи получают
одновременно новые элементы функциональности;
- наращивание по объектам, когда развертывание ведется от одной группы
пользователей к другой
- эволюционное развертывание с поэтапным расширением
функциональности.
Оповещение, подготовка и обучение
Персонал, находящийся в контакте с заказчиками (Служба Service Desk и Управление Взаимоотношениями с Заказчиками — CRM), операционный (обслуживающий) персонал и представители пользователей должны быть в курсе планов внедрения и его возможных последствий для повседневной деятельности. Для этого можно организовать совместное обучение, сотрудничество и совместное участие в приемке релиза. Необходимо согласовать распределение ответственностей, с соответствующим уведомлением каждого. При поэтапном развертывании релиза пользователи должны быть проинформированы о планах и времени, когда для них будут доступны новые функции. Необходимо заранее информировать весь задействованный персонал об изменениях в Соглашения> об Уровне Услуг (SLA), Операционных Соглашениях об Уровне Услуг (OLA) и Внешних Договора> (UC).
Распространение релизов и инсталляция
Управление Релизами осуществляет мониторинг процессов логистики/материально‐технического обеспечения по закупке, хранению, транспортировке, поставке и передаче программного и аппаратного обеспечения. Этот процесс поддерживается процедурами, регистрационными записями и такими сопроводительными документами, как упаковочные листы, что необходимо для предоставления достоверной информации в Процесс Управления Конфигурациями. Склады аппаратного и программного обеспечения должны быть надежными и доступными только для авторизованного персонала.
Для распространения и инсталляции программного обеспечения рекомендуется, по возможности использовать автоматизированные инструментальные средства. Это позволит сократить время, необходимое для распространения ПО, и повысить качество при сокращении затрат на ресурсы. Часто такие инструментальные средства также облегчают проверку успешности инсталляции. Перед началом любой инсталляции необходимо проверить, удовлетворяет ли среда, где предполагается внедрение релиза, необходимым требованиям, таким как достаточное дисковое пространство, безопасность, требованиям к окружающей среде или ограничениям эксплуатационных условий, например кондиционирование воздуха, площадь помещения, источники бесперебойного питания (UPS), сете вое питание и т. п.
После инсталляции необходимо обновить информацию в базе данных CMDB для облегчения проверки лицензионных соглашений.

Описание стратегии услуг Smart home.
Стратегия, обеспечивающая долгосрочное функционирование и успех, должна давать четкое понимание:
1.Какие услуги/сервисы должны быть предоставлены: Предоставляется средство по автоматизации сбора показателей с приборов домашнего учета коммунальных платежей.
2.Кому должны быть предложены услуги/сервисы: Услуга подразумевает массовое использование среди населения.Для хорошей работы фирмы доля рынка должна составлять не менее 15% .
3.Как должны развиваться внутренние и внешние рыночные отношения: Весь рынок базируется на конкуренции, продукт должен быть как минимум конкурентным, а для развития и укрепления нашей разработки на рынке мы должны освоить проект "Умный дом".
4.Какая конкуренция существует и потенциально возможна на рынке ваших услуг; каковы ваши объективные преимущества: Среди конкурентов не так много организаций, разработка имеет свои уникальные решения как в техническом плане, так и в конечном результате от использования нашего продукта.
5.Как заказчики будут принимать решения о выборе поставщика услуг: В первую очередь заказчик хочет видеть привлекательную стоимость продукта, а также качество.
6.Как клиент(ы) и остальные заинтересованные стороны будут воспринимать и оценивать стоимостное выражение сервисов, и каким образом эта ценность будет создаваться: Новшество и технологичность, должны вызывать большой интерес среди потребителей, а также удобство использования.
7.Как достичь финансовых наглядности и контроля стоимости услуг.
8.Как создать убедительные экономические обоснования, для привлечения инвестиций: Продукт должен иметь хорошую рентабельность и спрос, иметь уникальные свойства.
9.Как оптимально и эффективно распределить ресурсы.
10.Как измерять эксплуатационные качества сервиса.
Четыре «П» стратегии
Перспектива (perspective) – отличительная мировоззренческая концепция и направление деятельности.
1) Перспектива очевидна, так как информатизация и роботизация затрагивает все сферы нашего общества.
Позиция (position) – база, позволяющая быть конкурентоспособным.
2) Необходимо создать конкурентоспособную базу.
План (plan) – план достижения своих перспектив.
3) Разработка концепции, разработки, написание технической документации, анализ рынка, поиск инвестиций, производство, реклама, продажа готового продукта.
Паттерн (pattern) – фундаментальные способы осуществления чего-либо: характерные, подтвержденные временем, примеры принятия решений и действий.
Ценность сервиса (Service Value)
Ценность Сервиса (Service Value) определяется с точки зрения полученных заказчиком результатов значимых для бизнеса, и описываются с точки зрения сочетания двух компонент:
Полезность сервиса (Service Utility) – что клиент получает с точки зрения предоставляемой поддержки и устранения ограничений.
1) Потребитель получает полную техническую поддержку и обеспечение.
Гарантия сервиса (Service Warranty) – как сервис предоставляется, и его пригодность для использования, с точки зрения доступности, возможностей, непрерывности и безопасности.
2) Оборудование полностью ремонта-пригодно, обслуживание осуществляется специалистами фирмы, приблизительный срок обслуживания 1 раз в год.
Критические Факторы Успеха
Критические Факторы Успеха (Critical Success Factors, CSF) необходимы для определения и оценки степени успешности предоставления услуг.
Факторы успеха требуют идентификации, постоянного измерения и периодического пересмотра состава факторов и способов их оценки.
Сервис-Ориентированный Бухгалтерский учет (Service Oriented Accounting)
Сервис-Ориентированный Бухгалтерский учет (Service Oriented Accounting) – использование процесса управления финансами, для понимания сервиса с точки зрения потребления и ассигнования, и достижения взаиморасчета между корпоративными финансовыми системами и процессом управления обслуживанием.
Модели Предоставления Услуг
Модели Предоставления Услуг (Service Provisioning Models) – классификация и анализ различных моделей, которые могут быть выбраны клиентами и использоваться поставщиками услуг для создания и предоставления услуг, и финансовое воздействие в оншорных (on-shore), оффшорных (off-shore) и near-shore вариантах:
Управляемая Услуга (Managed Service) – когда организационная единица, требующая обслуживание, полностью финансирует предоставление себе этой услуги
Общая Услуга (Shared Service) – предоставление различных услуг одной или нескольким организационным единицам на основе общей инфраструктуры и ресурсов
Utility – услуги предоставляются на основе того, насколько это необходимо, как часто и в какое время каждому клиенту.
Дизайн и Развитие Организации
Дизайн и Развитие Организации (Organization Design and Development) – достижение определенных организационных форм и структур, которые позволяют осуществить стратегию обслуживания. Включает:
Стадии Развития Организации (Organizational Development Stages) – оказание услуг через сеть, директивы, делегирование, координацию и взаимодействие в зависимости от эволюционного состояния организации
Sourcing Strategy – Принятие обоснованных решений об источниках услуг в терминах: внутренние услуги (internal services), общие услуги (shared services), полный аутсорсинг обслуживания (full service outsourcing), консорциум (prime consortium) или выборочный аутсорсинг (selective outsourcing)
Сервисная Аналитика (Service Analytics) – Использование технологий для анализа эффективности обслуживания
Сервисные Интерфейсы (Service Interfaces) – механизмы, с помощью которых пользователи и другие процессы взаимодействуют с каждым сервисом
Управление Рисками (Risk Management) –управление портфелем рисков и отображение рисков на портфель услуг/сервисов (service portfolio).
Ключевые процессы и активности Service Strategy
В дополнение к разработке стратегии (Strategy Generation), том «Service Strategy» также включает следующие ключевые процессы:
Финансовый Менеджмент:
1.Управление портфелем услуг
2.Управления спросом
3.Финансовый Менеджмент
Процесс Финансового Менеджмента (Financial Management) охватывает функции и процессы, необходимые для управления бюджетом, бухгалтерского учета и налоговых требований. Финансовый Менеджмент предоставляет бизнесу и ИТ количественную финансовую оценку ценности услуг ИТ, стоимость активов, лежащих в основе предоставления этих услуг, а также оперативное прогнозирование. Обязанности и деятельность Финансового Менеджмента ИТ (IT Financial Management) не ограничиваются исключительно рамками финансовых вопросов ИТ и бухгалтерского учета. Многие организационные единицы взаимодействуют для создания и использования финансовой информации ИТ; агрегирования, коллективного использования и поддержки финансовых данных, которые им необходимы, распространение этой информации способствуют поддержке важных решений и действий.
Service Portfolio Management (SPM)
Процесс отвечает за управление Портфелем Услуг (Service Portfolio). Процесс Управления Портфелем Услуг рассматривает сервисы с точки зрения бизнес-ценности, которую они обеспечивают.
Управление Портфелем Услуг – непрерывный процесс.
Управление спросом
Процесс Управления спросом (Demand Management) является одним из важнейших аспектов управления услугами.
Неуправляемый спрос является источником риска для поставщиков услуг из-за неопределенности. Что приводит к тому, что избыточная производственная мощность создает затраты без создания ценностей, которые обеспечивают окупаемость.
Цель процесса Управления Спросом заключается в том, чтобы понять и влиять на клиентский спрос и обеспечить возможности для удовлетворения этого спроса. На стратегическом уровне это может включать анализ видов деятельности и пользовательских профилей. На тактическом уровне это может быть применение дифференциальных расценок для поощрения потребителей к использованию услуг ИТ в менее загруженные периоды.
Пакет Уровня Сервиса (Service Level Package, SLP) определяет уровень полезности и гарантии для Сервисного Пакета (Service Package) и предназначен для удовлетворения потребностей видов деловой активности.
Ключевые роли и ответственности Service Strategy
Книга «Service Strategy» определяет несколько специфичных ролей и обязанностей, связанных с выполнением успешной стратегии обслуживания, включая:
Менеджер Бизнес-Отношений (Business Relationship Manager, BRM): менеджеры бизнес-отношений устанавливают прочные деловые отношения с клиентом, понимая бизнес клиента и результаты клиентского бизнеса. BRM работают в тесном сотрудничестве с Менеджерами Продуктов, чтобы договариваться о производственных возможностях от имени клиентов.
Менеджер продукта (Product Manager, PM): менеджеры продуктов берут на себя ответственность за развитие и управление услугами на всем протяжении их жизненного цикла, а также несут ответственность за производственный потенциал, каналы распространения услуг, услуги, решения и пакеты, представленные в каталоге услуг.
Chief Sourcing Officer (CSO) – поборник стратегии источников сервисов (sourcing strategy) в организации. Совместно с директором информационных технологий (CIO) разрабатывает стратегию источников и отвечает за решения об источниках услуг.

Положение о конкурсе У.М.Н.И.К.

1. В соответствии с распоряжением Ректора ЮУрГУ №197 от 11 октября 2016 г. до 23 октября 2016 г. необходимо принять участие в независимой оценке качества образования по ссылке

Университеты России: расскажи о своем

Сообщение об участии отправить Горных Е.Н. до 12 часов 24 октября 2016 г.

2. Ответственным за направления подготовки совместно с кураторами групп организовать участие студентов всех форм обучения и курсов. Получить от старост групп сведения о количестве студентов, принявших участие в оценке.

Переход по ссылке делать только после регистрации на этом сайте. В противном случае Вас не посчитают со всеми вытекающими последствиями

Ключ

Перенесите баллы из каждого блока опросника в таблицу внизу. Проследите, чтобы общая сумма всех баллов в итоговой строке была равна 70. Если итог не равен 70, пересчитайте, пожалуйста, еще раз, где-то была допущена ошибка. (Примечании: при решении поставленных задач по формированию команды стартапа провести валидацию сохранённых результатов для каждого участника опроса)
Читать далее Тест Бельбина: ключ