Документирование процесса
Параметры процесса регламентируются следующими внутренними отчетами:
отчеты о времени исполнения: разделенные на контроль проблем, контроль ошибок и проактивное управление проблемами, а также разделенные между группой технической поддержки и поставщиками услуг.
качество продукта: детальная информация об инциденте, проблеме и известной ошибке.
эффективность процесса управления проблемами: точное количество инцидентов до и после решения проблемы, зарегистрированные проблемы, количество поданных запросов на изменения и решенных известных ошибок.
баланс между реактивным и проективным управлением проблемами:
качество разработанных продуктов: продукты, переданные от разработчиков, должны иметь высокое качество, иначе они могут создать новые проблемы. Для мониторинга качества важны отчеты о новых продуктах и имеющихся в них известных ошибках.
статус и план работ по открытым проблемам.
предложения по улучшению процесса управления проблемами.
план обеспечения качества услуг.
Содержание отчетов зависит от сферы действия процесса управления
проблемами. Если в сферу процесса попадают продукты из среды разработки, то
управление проблемами может определять известные ошибки и вести их мониторинг
даже на этапе разработки программного обеспечения.
Описание процесса
Управление отчетностью по услугам - предоставление информации по услуге в формализованном виде.
Цель: составление отчетностей может быть достаточно много: от простого получения информации о проделанной работе до анализа отчетности для повышения эффективности и качества предоставления услуг.
Задачи: обеспечить документированную взаимосвязь между заказчиком и поставщиком услуг, повысить осведомленность начальства о выполненной работе.
Окружение процесса
· Управление проблемами
Отчеты по управлению проблемами могут быть самыми объемными, поскольку описывают все проблемы, которые были зафиксированы в течение работы. Обычно отчеты включают в себя: время исполнения, детальную информацию о проблемах и инцидентах, количество инцидентов до и после решения проблемы, количество запросов на изменения, отчеты о том, что было сделано и что будет сделано и прочее.
· Управление изменениями
Отчетность по изменениям может включать: количество изменений, причины, количество успешных преобразований и количество неудачных, количество инцидентов, связанных с изменениями, график тенденций за предыдущие периоды.
· Управление конфигурациями
В отчетность по управлению конфигурациями входит обычно: информация о качестве, различие между регистрационными данными и реальной картиной, количество случаев, когда использовалась незарегистрированная конфигурация, перечень конфигурационных единиц, данные о структуре и развитии ИТ-инфраструктуры, расходы.
· Управление информационной безопасностью
Заказчик должен обладать наиболее полной информацией о достигнутых
результатах в управлении. Заказчик также информируется обо всех инцидентах,
связанных с безопасностью.
Метрики процесса подготовки отчетности по услугам
|
Метрика |
Описание |
Задача метрики |
Аудитория |
|
Процент отчетов, не использовавшихся в течение года в области ИТ. |
Количество отчетов, которыми долго не пользовались или ненужные отчеты. |
Неиспользуемые документы должны периодически пересматриваться с точки зрения их существенности и возможности удаления. |
Владелец процесса, руководство ИТ-отдела, владелец процесса SLA, члены команды, владелец процесса SIP. |
|
Число несоответствий между отдельными отчетами и общим отчетом по управлению услугами по проекту ИТ. |
Отчеты должны быть взаимно согласованы и отвечать политике организации. Метрика выявляет любые несоответствия. |
Если централизованная подготовка всех отчетов не позволяет достичь согласованности, необходима ручная перекрестная проверка. |
Владелец процесса, руководство ИТ-отдела, владелец процесса SLA, члены команды, владелец процесса SIP. |
|
Число инцидентов, относящихся к ошибкам в отчетах. |
Инциденты, которые связаны с ошибками в отчетности. |
Процесс управления отчетностью должен работать так, чтобы ошибки или неверные сведения не приводили к инцидентам. |
Владелец процесса, руководство ИТ-отдела, владелец процесса SLA, члены команды, владелец процесса SIP. |
|
Число подготовленных отчетов за год, месяц, квартал. |
Количество отчетов, подготовленных за определенный период. |
Отчетность по периодам позволяет проводить анализ и улучшать качество выполнения проекта. |
Владелец процесса, руководство ИТ-отдела, владелец процесса SLA, члены команды, владелец процесса SIP. |
|
Число обращений в Service Desk. |
Количество проблем, которые возникли у пользователей в течение работы. |
Число проблем, с которыми клиент обратился в службу необходимо уменьшать, это возможно только при получении информации по всем обращениям. |
Владелец процесса, руководство ИТ-отдела, владелец процесса SLA, члены команды, владелец процесса SIP. |
|
Процент необработанных обращений в Service Desk. |
Количество проблем, решенных до принятия мер сотрудниками службы поддержки. |
Примерный процент ложных проблем. |
Владелец процесса, руководство ИТ-отдела, владелец процесса SLA, члены команды, владелец процесса SIP. |
|
Процент удовлетворенных скоростью реагирования клиентов на обращение в службу поддержки. |
Примерная удовлетворенность клиентов службой поддержки. |
Плавающая метрика, которая предоставляет информацию об удовлетворенности сервиса. Плавающая, потому что клиент может ошибиться в оценке либо специально ухудшить показатель удовлетворенности. |
Владелец процесса, руководство ИТ-отдела, владелец процесса SLA, члены команды, владелец процесса SIP. |
|
Количество реактивных отчетов. |
Отчеты, которые показывают, что уже произошло. |
Отображает количество проблем, которые предотвратить не удалось. Показатель со временем должен улучшаться. |
Владелец процесса, руководство ИТ-отдела, владелец процесса SLA, члены команды, владелец процесса SIP. |
|
Количество проактивных отчетов. |
отчеты с прогнозами предоставления услуг. |
Для заблаговременного предупреждения о важных событиях и позволяет заранее предпринять меры. |
Владелец процесса, руководство ИТ-отдела, владелец процесса SLA, члены команды, владелец процесса SIP. |
|
Количество показателей для отчетности по услугам. |
Определенный список показателей для различных видов отчетов. |
Благодаря общему списку показателей можно легче проводить анализ и принимать меры для улучшения качества предоставления услуг. |
Владелец процесса, руководство ИТ-отдела, владелец процесса SLA, члены команды, владелец процесса SIP. |
Документирование процесса
· Отчет об уровне сервиса (информация о реальном уровне предоставления услуг);
· Бухгалтерский отчет - суммарный список статей расходов и доходов по проекту;
· Отчет о результатах выполненных работ - успешные и безуспешные работы по проекту;
· Отчет о проблемах - список проблем, выявленные в течение выполнения проекта;
· Отчеты об инцидентах - список инцидентов, выявленные после решения проблем;
· Отчеты о сбоях - список зарегистрированных сбоев в работе;
· Клиентская отчетность - необходимая информация по проекту для заказчика (включает в себя всю информацию, необходимую клиенту: затраты, проблемы, инциденты и пр.);
· Отчеты о договорах, подписанных с подрядчиками и потребителями;
· Еженедельный отчет команды проекта (содержит перечень проделанных работ, затраченное время, работы с нарушением сроков, задачи на будущее);
· Статус-отчет (отражает как обстоят дела с проектом в данный момент, какие обстоятельства могут помешать успешному завершению проекта, ключевые метрики, общее количество рисков);
· Реестр рисков (результат идентификации рисков, данных их анализа и планы по реагированию для наиболее важных рисков);
· Реестр неотложных вопросов (как идет работа с рисками и непредвиденными обстоятельствами. К примеру, замена ключевого сотрудника. Реестр заполняется по важности вопросов - от «незначительного» до «критического»);
· Резюме для руководства - высокоуровневый отчет, задачей
которого является обеспечение руководства четким пониманием статуса проекта,
пользы, которую он принесет, влияние результатов проекта на общее положение дел
компании. Обычно в таких отчетах должны присутствовать реальные факты.
При постоянном повышении зависимости современных организаций от ИT-процессов большое значение получает их эффективный и качественный мониторинг и защита. С высоким ростом количества изменений в ИT-процессах растет и потребность в контроле за проведением изменений.
Все изменения ИT-инфраструктуры осуществляются в сложной распределенной среде. Для современных приложений, сервисов и услуг, основанных на клиент-серверной архитектуре такие изменения, зачастую отражаются как на серверной части, так и на клиентской. В большинстве подобных случаев установка, запуск и внедрение новых релизов программных и аппаратных продуктов требует к себе тщательного и распределённого планирования. Для процесса управления релизами используется проектный подход к осуществлению изменений в ИT-услугах, и он включает технические и нетехнические особенности изменений.
Описание процесса
Под понятием релиз подразумевается набор новых или/и измененных конфигурационных единиц, которые могут вместе испытываться и внедряться в рабочую ИT среду. Релиз определяется RFC (запрос на изменения), для исполнения которого он внедряется в работу.
Управление релизами (Release management) - это процесс, который отвечает за установку, внедрение и контроль качества всех возможных видов аппаратно-программного обеспечения, развернутого в ИT-среде. А также в рамках такого процесса, как управление релизами создаются и принимаются политики внедрения новых версий программно-аппаратных служб.
Релиз - это набор новых и/или измененных конфигурационных единиц, в отношении которых осуществлено тестирование и которые рекомендованы для использования одновременно.
Управление релизами и развертыванием занимается предоставлением и тестированием всех возможностей для реализации услуг, предусмотренных на начальном этапе проектирования.
Главным предназначением процесса управления релизами является полное обеспечение качества продуктивной среды вследствие использования формальных процедур, тестов и проверок при вводе в эксплуатацию новых релизов и версий. Главным отличием от процесса управления изменениями, который в первую очередь занимается верификацией, процесс управления релизами осуществляет процедуру внедрения. Управление релизами выполняется в сотрудничестве с управлением конфигурациями и управлением изменениями, что обеспечивает своевременное обновление единой базы CMDB (база данных управления конфигурациями) с учетом каждого внедряемого релиза. Управление релизами обеспечивает обновление контентного содержания релиза (программного кода) в DSL - библиотека эталонного программного обеспечения. При помощи базы CMDB еще отслеживается спецификация аппаратных средств, инструкции, руководства по инсталляции, установке, внедрению, также сетевые конфигурации и т.д. Весь запас аппаратной части, в том числе стандартные базовые конфигурации, хранятся на специальном складе эталонного аппаратного обеспечения, который называется DHS. Главным объектом, на который направлена деятельность процесса управления релизами в первую очередь является ПО.
В масштабных проектах управления релизами должно внедряться в общий план затрат проекта как неотъемлемая его составная часть, без которой невозможно нормальное функционирование системы для достаточного финансового обеспечения работы процесса. Некоторая часть ежегодного бюджета должна быть распределена на повседневные работы, которые включают затраты на незначительные изменения. Расходы, которые возникают при внедрении процесса - менее значительны, если сравнивать их с потенциальными потерями, которые вызваны недостатками в планировании и контроле за аппаратно-программными частями, к которым относят:
ü длинные перерывы в работе вследствие некачественного планирования выпуска релизов ПО;
ü выполнение большого количества одинаковой работы из-за наличия копий программного обеспечения различных версий;
ü малоэффективное или неэффективное использование ресурсов из-за наличия недостаточной информации об их местонахождении;
ü потеря файлов-дистрибутивов, которая вызывает дополнительную трату средства на повторную закупку программ;
ü отсутствие антивирусной защиты, которое приводит к необходимости «лечения» всех частей сети, между которыми осуществлялось взаимодействием и передача зараженного ПО.
Цель: управление, дистрибуция и распространение используемых в продуктивной среде версий (релизов) программно-аппаратного обеспечения, которое находится на поддержке IT-службы для поддержания высокого уровня и качества услуг.
Требования
1. Обсуждение, формирование и согласование с заказчиками и инвесторами планов запуска релизов, сроков эксплуатации и внедрения, а также процессы развертывания;
2. Обеспечение гарантии того, что каждый пакет для релиза включает в себя набор взаимосвязанных и совместимых между собой компонентов;
. Управление релизом и его компонентами, координация действий, обусловленных процессом внедрения программного обеспечения;
. Обеспечение гарантии того, что каждый пакет для всех релизов может быть протестирован, отлажен, установлен или исправлен (при возникновении необходимости);
. Обеспечение гарантии того, что все изменения происходят в соответствии с деятельностью процесса управления релизами;
. Постоянное ведение отчётности и управление возникающими рисками, проблемами, которые связанны с новой внедряемой или уже существующей, но частично измененной услугой. При необходимости осуществление дополнительных корректирующих действий;
. Обеспечение открытого доступа к информации о релизах для бизнес-заказчиков, с целью наиболее эффективного использования новой или измененной услуги;
. Обеспечение открытого доступа к информации о релизах для рабочего персонала, с целью постоянной поддержки и управления услугой.
Задачи
o Создание планов, обеспечение координации, внедрение аппаратно- программных средств.
o Создание и внедрение последовательности выполнения операций и процедур для внедрения, распространения и инсталляции любых изменений в ИT-сервисах.
o Обеспечение мониторинга и уверенность в безопасности программно-аппаратных средств, которые когда-либо изменениям, и обеспечение гарантии того, что в продуктивной среде используются корректные, легальные, авторизованные и протестированные версии программных продуктов.
o Коммуникации, обучение и оповещение пользователей программного обеспечения, разработка с учетом их ожиданий и пожеланий, использование обратной связи при планировании и внедрении новых релизов ПО.
o Определение качественного и количественного состава релизов, а также планирование их внедрения при участии процесса Управления Изменениями.
o Установка новых версий программно-аппаратной архитектуры в продуктивную инфраструктуру под полным контролем процесса управления изменениями, а также при поддержке процесса управления конфигурациями. Релиз может содержать неограниченное количество конфигурационных единиц, а также программно-аппаратные службы документацию, такую как отчеты, руководства по поддержке и другое.