Предоставление электронных публичных услуг (стр. 3 )

Статус инцидента должен отражать его текущее положение в жизненном цикле. В течение жизненного цикла инцидента необходимо, чтобы запись о нем поддерживалась в актуальном состоянии, что позволяет получать свежие данные о ходе обработки запроса.

Следует регистрировать следующие обновления записи об инциденте:

-  сотрудник, сделавший изменение в записи;

-  детальное описание изменения;

-  дата и время изменения;

-  причина внесения изменений;

-  затраченное время.

Приоритет инцидента должен определяться его влиянием на процессы в организации и срочностью, с которой необходимо обеспечить разрешение или обходное решение. Целевые показатели для разрешения инцидентов или обработки запросов должны быть включены в Соглашение об уровне услуг.

Все инциденты должны регистрироваться в ЦЭП автоматически, либо сотрудниками.

После получения уведомления об инциденте ЦЭП должен записывать основные сведения, включая время и полученные подробности о симптомах, затем, при наличии запроса на обслуживание, заявка обрабатывается. Для дополнительной записи об инциденте на основе Конфигурационной базы данных учетных элементов происходит выбор учетных элементов, являющихся причиной инцидента. Следующими действиями, выполняемыми ЦЭП, являются установка соответствующего приоритета, оценка инцидента, предоставление рекомендаций по его разрешению. После успешного разрешения инцидента необходимы закрытие записи о нем, регистрация действий, связанных с его разрешением. После неудачной попытки разрешения инцидента или при выяснении, что необходим более высокий уровень поддержки, происходит передача инцидента специализированной группе.

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

5.1.2 Действия, осуществляемые в процессе управления инцидентами

Для продуктивной работы процесса управления инцидентами необходимы:

-  своевременно обновляемая Конфигурационная база данных учетных элементов;

-  разработка своевременно обновляемой базы данных проблем и ошибок для хранения существующих разрешений и обходных решений;

-  обеспечение тесной связи с процессом управления уровнями обслуживания для определения требуемых показателей по времени реакции на инцидент.

Процесс управления инцидентами получает необходимую для обработки информацию из следующих источников:

-  сведения об инциденте, представленные ЦЭП, подразделением обслуживания сетей или эксплуатационной службой;

-  сведения о конфигурации из Конфигурационной базы данных учетных элементов;

-  результаты привязки инцидента к проблемам и известным ошибкам; сведения о разрешении;

-  ответ на запрос на изменение, приводящий к разрешению инцидентов.

В ходе выполнения действий и требований процесса управления инцидентами должна быть получена следующая информация:

-  запрос на изменение для разрешения инцидента;

-  обновленная запись об инциденте;

-  разрешенные и закрытые инциденты;

-  коммуникации с заказчиками;

-  управленческая информация, отчетность.

Процесс управления инцидентами должен состоять из следующих действий:

-  обнаружение и регистрация инцидента;

-  классификация и первичная поддержка;

-  расследование и диагностика;

-  разрешение и восстановление;

-  закрытие инцидента;

-  контроль, мониторинг, отслеживание и коммуникации.

Для поддержки контроля над полным жизненным циклом инцидента для каждого действия следует регистрировать: имя/идентификатор группы специалистов, которые записывают действия, тип действия (маршрутизация, диагностика, восстановление, разрешение, закрытие, и т. д.), дата/время действия, описание и результат действия.

5.1.2.1 Обнаружение и регистрация инцидентов

В процессе обнаружения и регистрации инцидента должны поступать сведения об инциденте, на основании которых происходит запись основных сведений о нем, затем идет сигнал специализированной группе поддержки при необходимости и начало процедур обработки запроса на обслуживание. Все инциденты следует регистрировать, чтобы они попали в базу данных управления инцидентами. Симптомы, основные данные для диагностики и информация об учетных элементах, связанных с инцидентом, должны быть включены в записи об инциденте во время его обнаружения и записи.

В записях об инциденте должны регистрироваться следующие данные:

-  уникальный регистрационный номер;

-  класс инцидента;

-  дата/время создания или изменения записи;

-  имя/ идентификатор специалиста или группы специалистов, которые создают или изменяют учетную запись;

-  имя/ подразделение/ телефонный номер/ местоположение обращающегося пользователя;

-  способ обратной связи;

-  описание симптомов;

-  категория или подкатегория;

-  влияние/срочность/приоритет;

-  статус инцидента (активный, ожидание, закрыт, разрешен, в работе, новый, передан специалисту);

-  учетные элементы, задействованные в инциденте;

-  группа поддержки/специалист, которому передан инцидент;

-  проблема/известная ошибка, связанная с инцидентом;

-  дата и время разрешения;

-  категория закрытия;

-  дата и время закрытия.

Эти данные необходимы для разрешения инцидента, последующего восстановления и для управленческой информации по типам инцидентов и статистике их возникновения. Инцидент должен обрабатываться в соответствии со стандартными процедурами управления уровнем обслуживания.

5.1.2.2 Классификация и первичная поддержка инцидентов

В процессе классификации и первичной поддержки инцидентов должны поступать сведения о конфигурации из Конфигурационной базы данных учетных элементов, а также результат привязки инцидента к проблемам и известным ошибкам.

Для идентификации причины инцидента необходимо проанализировать записи базы данных управления инцидентами и выполнить следующие действия:

-  классификация инцидентов (см. 5.1.3);

-  привязка к проблемам и известным ошибкам;

-  информирование процесса управления проблемами об обнаружении новых проблем, об инцидентах, для которых не было найдено аналогов;

-  присвоение степени влияния и срочности;

-  определение приоритета;

-  оценка сведений о связанных конфигурациях;

-  предоставление первичной поддержки;

-  закрытие инцидента или его маршрутизация на специализированную группу поддержки, информирование пользователя.

Инцидент должен быть классифицирован. В процессе классификации должны быть определены причины инцидента и соответствующие действия по его разрешению. Классификация используется для определения оказываемой услуги, с которой связан инцидент, связи ее с Соглашением об уровне услуг, выбора специалистов для обработки инцидента, определения приоритета и влияния инцидента на процессы организации, определения наличия связей с известными ошибками и решениями. При классификации инцидентов необходимо предоставление максимального количества информации.

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

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

Срочность инцидента – скорость, с которой его необходимо разрешить.

5.1.2.3 Расследование и диагностика инцидентов

В процессе расследования и диагностики инцидента должны поступать обновленные сведения об инциденте, конфигурации из Конфигурационной базы данных учетных элементов, а также выполняться действия по анализу и сбору сведений об инциденте, поиску обходного решения или передачи инцидента группе поддержки.

После передачи инцидента группе поддержки она должна:

-  обработать инцидент;

-  указать дату и время для регулярного обновления статуса инцидента;

-  предоставить рекомендации ЦЭП по найденным обходным решениям;

-  сопоставить инцидент с известными ошибками, проблемами, решениями;

-  определить решение инцидента, обновить необходимые данные;

-  передать инцидент ЦЭП для его закрытия.

Процесс расследования и диагностики может повторяться циклически, по мере устранения причин возникновения инцидента.

5.1.2.4 Разрешение инцидента и восстановление услуги

Результатом процесса разрешения инцидента и восстановления услуги должны быть обновленные сведения об инциденте, ответы на запрос на изменение, приводящие к разрешению инцидентов, обходные решения и способы разрешения инцидента.

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

5.1.2.5 Закрытие инцидента

Результатом процесса закрытия инцидента должны быть обновленные сведения об инциденте и разрешенный инцидент.

В процессе закрытия инцидента необходимо осуществлять подтверждение разрешения инцидента его заявителем. После закрытия инцидента ЦЭП должен удостовериться, что:

-  сведения о действиях по разрешению инцидента лаконичны и понятны;

-  существует четкая классификация исходной причины инцидента;

-  действия по разрешению инцидента согласованы с заказчиком.

5.1.2.6 Контроль, мониторинг, отслеживание и коммуникации

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

ЦЭП несет ответственность за контроль и наблюдение за разрешением всех открытых инцидентов. Для этого необходимо регулярно выполнять следующие действия:

-  отслеживать статус и ход разрешения всех открытых инцидентов;

-  проверять соответствие уровням обслуживания;

-  отмечать инциденты, передаваемые между специализированными группами;

-  отдавать приоритет мониторингу инцидентов с высокой степенью влияния;

-  информировать пользователей, затронутых инцидентом.

Результатом выполнения этих действий являются управленческие отчеты о ходе разрешения инцидента, отчеты и коммуникации с заказчиком.

5.1.3 Классификация инцидентов

Классификация инцидентов должна быть корректно проведена для достижения следующих целей:

-  определения услуги или оборудования, с которыми связан инцидент;

-  выбора тех специалистов, которые наилучшим образом справятся с устранением инцидента;

-  определения приоритета и влияния на функционирование процессов предоставления публичных услуг;

-  определения критериев привязки при выборе того или иного решения;

-  определения матрицы отчетности для управленческой информации.

Уровни классификации зависят от требуемого уровня детализации. Детальная классификация обеспечивает более эффективное использование управленческой информации, которая периодически должна анализироваться с целью использования только новейших данных.

5.1.4 Показатели эффективности процесса управления инцидентами

Для улучшенного мониторинга и управленческой информации по качеству услуг, обеспечения снижения влияния на процессы предоставления публичных услуг, лучшего использования персонала, исключения потерянных и неправильно введенных инцидентов и запросов на обслуживание необходимо измерять такие показатели как:

-  общее количество инцидентов;

-  среднее фактическое время, затраченное на разрешение инцидента или поиск обходного решения;

-  процент инцидентов, обработанных в рамках согласованного времени реакции;

-  средние затраты на инцидент;

-  процент инцидентов, закрытых ЦЭП, без обращения к специализированным группам;

-  обработанные инциденты по каждой рабочей станции ЦЭП;

-  количество и процент инцидентов, разрешенных удаленно.

5.2 Процесс управления проблемами

Цель процесса управления проблемами – минимизировать количество и отрицательное влияние инцидентов и проблем, вызваноe ошибками в ИТ-инфраструктуре, на процессы предоставления публичных услуг. Для достижения данной цели необходимо осуществлять поиск причин инцидентов и действия по улучшению или исправлению ситуации.

В процесс управления проблемами должны входить действия, связанные с реагированием на инциденты, и упреждающие действия. Действия управления проблемами должны включать обновление рекомендованных обходных решений и записи о проблеме для поддержки контроля инцидентов.

Результатом процесса управления проблемами должно быть представление информации об обнаруженных проблемах, известных ошибках и оформленных запросах на изменение.

5.2.1 Основные требования, предъявляемые к процессу управления проблемами

К процессу управления проблемами предъявляются следующие требования:

-  хранящаяся информация должна быть организована и легко доступна;

-  обновление документации (технологии, доступные внешние решения, практический опыт, частота и влияние повторяющихся инцидентов) должно происходить регулярно;

-  проведение детального анализа процесса управления проблемами и составление соответствующей документации;

-  наличие квалифицированного персонала;

-  наличие хранилища информации, основанного на интегрированных средствах управления услугами;

-  использование экспертных систем.

Проблемы и известные ошибки должны выявляться при помощи анализа инцидентов по мере их возникновения и в различные промежутки времени, анализа ИТ-инфраструктуры, подготовки базы знаний, деятельности разработчиков и поставщиков при вводе в эксплуатацию новых продуктов.

5.2.2 Действия процесса управления проблемами

В рамках процесса управления проблемами необходимо осуществлять контроль проблем и ошибок, упреждающее управление проблемами. Все проблемы должны быть известны и зарегистрированы в рамках процесса управления проблемами.

Для осуществления процесса управления проблемами требуются сведения об инцидентах, сведения о конфигурации из Конфигурационной базы данных учетных элементов, обходные решения.

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

Процесс управления проблемами состоит из следующих действий:

-  контроль проблем;

-  контроль ошибок;

-  упреждающее предотвращение проблем;

-  определение тенденций;

-  получение управленческой информации;

-  анализ крупных проблем (осуществляется после разрешения каждой крупной проблемы).

5.2.2.1 Контроль проблем

Контроль проблем состоит в эффективной и результативной обработке проблем. Основной целью является определение корневой причины, вызвавшей неисправность и обеспечение ЦЭП информацией и рекомендациями об обходных решениях. Контроль проблем зависит от качества контроля инцидентов и предоставляет рекомендации о лучших обходных решениях.

В ходе контроля проблем необходимо выполнять следующие действия:

-  идентификация и запись проблемы;

-  классификация проблемы;

-  анализ и диагностика проблемы;

-  запрос на изменение;

-  разрешение и закрытие проблемы.

5.2.2.1.1 Идентификация и запись проблемы

Идентификация проблемы должна осуществляться в случае, когда выполняется одно или несколько условий, перечисленных ниже:

-  при первичной поддержке и классификации инцидента не удалось привязать его к существующим проблемам и известным ошибкам;

-  инцидент является повторяющимся;

-  инцидент не связан с существующими проблемами и известными ошибками;

-  анализ ИТ-инфраструктуры указывает на проблему, которая потенциально может привести к инцидентам;

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

Записи о проблемах должны содержаться в Конфигурационной базе данных учетных элементов. Записи о проблемах соединены со всеми сопутствующими им записями об инцидентах.

5.2.2.1.2 Классификация проблем

В процессе классификации требуется определять объем усилий, требуемых для нахождения и восстановления вышедших из строя учетных элементов, категорию, влияние, срочность и приоритет проблемы. Категории проблем распределены по связанным группам или областям знаний (аппаратное обеспечение, ПО, коммуникационное обеспечение, ПО поддержки и т. д.).

Влияние проблемы определяет распределение усилий по поддержке публичных услуг. При определении приоритета проблемы необходимо принимать во внимание срочность, влияние, риски и доступность ресурсов.

Срочность в свою очередь должна определять степень задержки, которую можно допустить при разрешении проблемы или ошибки. На срочность проблемы влияют следующие аспекты:

-  доступность временного устранения ошибки;

-  существование обходного решения;

-  возможность планируемой задержки разрешения проблемы;

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

5.2.2.1.3 Анализ и диагностика проблем

Анализ и диагностика проблемы должны определять причину неисправности в зарегистрированном учетном элементе, после чего необходимо начинать работу системы контроля ошибок.

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

При структурном анализе и диагностике проблем должны применяться следующие методы:

-  Кепнер и Трего – согласно методу анализ проблем должен быть систематическим процессом, направленным на их решение. Метод выделяет фазы анализа проблем:

1)  - определение проблемы;

2)  - описание проблемы, включая сущность, особенности, местоположение, время и размеры;

3)  - определение возможных причин;

4)  - тестирование наиболее вероятной причины;

5)  - проверка настоящей причины;

-  диаграммы Ишикавы – причинно-следственные диаграммы, показывающие факторы, влияющие на проблему;

-  метод “мозгового штурма”;

-  методы блок-схем.

В ходе процесса анализа и диагностики проблем необходим доступ к документации на все продукты в ИТ-инфраструктуре в качестве справочной информации, как для процесса, так и для персонала службы поддержки. Эта информация должна включать документацию по прикладным системам, системному ПО, внутренним сервисным программам, сетевому аппаратному обеспечению и ПО, общим диаграммам конфигураций сетей.

5.2.2.2 Контроль ошибок

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

Контроль ошибок должен объединять среду разработки и среду эксплуатации. Ошибки в программном обеспечении на этапе разработки могут влиять на работу в среде эксплуатации. Информация об известных ошибках, найденных в среде разработки или среде сопровождения, должна быть передана в среду эксплуатации.

В ходе контроля ошибок необходимо выполнение следующих действий:

-  идентификация и запись ошибок;

-  оценка ошибок;

-  запись о ходе разрешения ошибок;

-  закрытие ошибок;

-  мониторинг проблем и прогресса разрешения ошибок.

Контроль ошибок напрямую связан и действует совместно с процессами управления изменениями. Процесс контроля ошибок должен состоять из этапов обнаружения и записи ошибки, оценки ошибки, записи решения по ошибке, закрытия ошибки и сопутствующей проблемы.

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

Ошибки должны определяться и записываться в порядке расследования и диагностики – действий по контролю проблем.

Процедура разрешения каждой известной ошибки должна записываться в системе управления проблемами. Необходимо, чтобы все данные об учетных элементах, симптомах, действиях по разрешению или обходному решению, связанные со всеми известными ошибками, находились в базе данных известных ошибок. Эти данные должны быть доступны для привязки инцидентов, нахождения обходных решений и предоставления управленческой информации.

После внедрения изменений по устранению ошибки соответствующие записи об известной ошибке должны закрываться вместе со всеми связанными записями об инцидентах и проблемах. Контроль ошибок несет ответственность за мониторинг хода работ, связанных с разрешением известных ошибок.

Подготовка запроса на изменение входит в обязанности процесса контроля ошибок.

5.2.2.3 Упреждающее предотвращение проблем

Упреждающее предотвращение проблем должно охватывать действия, нацеленные на нахождение и разрешение проблем до их возникновения, сводя к минимуму отрицательное воздействие на оказание публичных услуг.

При этом необходимо выполнять следующие действия:

-  анализ тенденций;

-  действия по поддержке;

-  обеспечение организации информацией.

Упреждающее предотвращение проблем должно обеспечивать улучшение качества предоставления публичных услуг и более эффективное использование доступных информационных ресурсов.

Задача упреждающего управления проблемами заключается в эффективном направлении ограниченных ресурсов по поддержке услуг, определению проблемных мест, оказывающих наибольшее негативное влияние на процесс предоставления публичных услуг.

Основная упреждающая деятельность процесса управления проблемами - это анализ тенденций и направлений действий по предотвращению возникновения проблем. Отчеты по анализу инцидентов и проблем должны предоставлять информацию об упреждающих мерах, которые могут улучшить качество предоставляемых публичных услуг. Анализ инцидентов и проблем должен определять тенденции, неисправности определенного типа, находящиеся в их начальных стадиях, повторяющиеся инциденты и связанные с их возникновением проблемы.

5.2.2.4 Определение тенденций

Определение тенденций приводит к определению потенциальных проблемных мест, которые нуждаются в расследовании. Определение и анализ тенденций должны приводить к идентификации неисправностей в ИТ-инфраструктуре, определению общих проблемных мест, нуждающихся в большем внимании со стороны службы поддержки.

5.2.2.5 Получение управленческой информации

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

В состав управленческой информации должны быть включены:

-  количество оформленных запросов на изменение;

-  влияние запросов на изменение на доступность и надежность предоставляемых публичных услуг;

-  объем времени, потраченного на расследование и диагностику проблемы по каждой организационной единице;

-  количество и влияние инцидентов, возникающих до закрытия корневой проблемы;

-  пропорция усилий, потраченных на реагирование по поддержке, по отношению к запланированным усилиям в процессе управления проблемами;

-  планы по разрешению открытых проблем по отношению к ресурсам и бюджету;

-  описание предпринимаемых действий.

5.2.2.6 Анализ крупных проблем

При разрешении каждой крупной проблемы должен выполняться ее анализ. Анализ необходим для определения верных и неверных действий по устранению проблемы, мер по предотвращению повторного появления данной проблемы.

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

5.2.3 Показатели эффективности процесса управления проблемами

Историческая информация о контроле инцидентов и проблем дает возможность получить метрики, показывающие качество обслуживания и производительность процесса оказания публичных услуг. Метрикой эффективности по отношению к согласованным уровням обслуживания являются частота и длительность проблем.

Для улучшения качества предоставляемых публичных услуг, уменьшения количества инцидентов, улучшения процесса обучения персонала, повышения процента запросов, разрешенных во время первого обращения, ЦЭП должен рассчитывать следующие показатели:

-  общее количество проблем;

-  общее количество ошибок;

-  среднее фактическое время, затраченное на разрешение проблем или поиск обходного решения;

-  средние затраты на разрешение проблемы или ошибки;

-  количество и процент проблем, разрешенных удаленно;

-  количество предупрежденных проблем ИТ-инфраструктуры, в том числе и процессом управления доступностью.

Взаимодействие между процессом управления проблемами и процессом управления доступностью приводит к улучшению качества обслуживания.

Процесс управления проблемами должен регулярно анализировать полученные достижения по всем целевым показателям.

5.3 Процесс управления изменениями

Цель процесса управления изменениями заключается в обеспечении использования стандартных методов и процедур для продуктивной и своевременной обработки изменений, для минимизации влияния инцидентов, связанных с изменениями, на качество предоставляемых публичных услуг.

Информация о процессах управления изменениями должна быть открытой для перехода к новому состоянию при проведении изменений.

Для выполнения данного процесса необходимо наличие запросов на изменение, Конфигурационной базы данных учетных элементов, согласованного графика изменений.

В процессе управления изменениями должны составляться согласованный график изменений, запросы на изменение, отчеты управления изменениями.

5.3.1 Основные требования, предъявляемые к процессу управления изменениями

Процесс управления изменениями должен ежедневно управлять происходящими изменениями.

К процессу управления изменениями предъявляются следующие требования:

-  проведение фильтрации изменений;

-  составление плана изменений;

-  проведение анализа и закрытия запросов на изменение;

-  составление управленческой отчетности.

5.3.1.1 Фильтрация изменений

Фильтрация изменений должна осуществляться по отношению к следующим информационным объектам:

-  аппаратному обеспечению;

-  коммуникационному оборудованию и ПО;

-  системному ПО;

-  прикладному ПО, находящемуся в эксплуатации;

-  документации и процедурам сопровождения и поддержки систем, находящихся в эксплуатации.

В рамках процесса управления изменениями должно предоставляться подтверждение любого предложенного изменения. Управление изменениями не отвечает за идентификацию компонентов, затронутых изменением, обновление записей об изменениях, релизы новых или измененных компонентов. Все действия в процессе изменения должны записываться, по мере их проведения, в журнал управления изменениями.

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

До утверждения каждого изменения необходимо рассмотрение рисков для процессов предоставления публичных услуг, а также рассмотрение оценки влияния и ресурсов. Утверждение изменения должно включать финансовое, техническое и организационное утверждение. Финансовое утверждение определяет рамки бюджета изменения. Техническое утверждение определяет осуществимость, рациональность и выполнимость изменения без ущерба для процесса предоставления услуг. Организационное утверждение определяет требования, обусловленные предоставлением публичных услуг, и ожидания участников взаимодействия и пользователей публичных услуг.

5.3.1.2 Составление плана изменений

Для улучшения процесса управления изменениями необходимо координировать разработку и распространение согласованных плана и графика изменений, а также ожидаемой доступности услуг. Эта документация должна быть общедоступна.

Согласованные план и график изменений должны содержать сведения обо всех изменениях, утвержденных к внедрению, и предполагаемые даты их внедрения. Ожидаемая доступность услуги должна содержать сведения об изменениях в Соглашении об уровне услуг и о доступности услуг при планируемых изменениях.

5.3.1.3 Анализ запросов на изменение

В процессе управления изменениями должен проводиться анализ всех внедренных изменений. Целью анализа является установить, что:

-  изменение привело к ожидаемому эффекту и достигло поставленных целей;

-  пользователи удовлетворены результатами;

-  выявлены все недочеты;

-  не возникло побочных эффектов в функциональности, доступности, производительности, безопасности, возможности обслуживания;

-  объем ресурсов, использованных для внедрения изменения, соответствует запланированному объему;

-  изменение было внедрено своевременно;

-  план отката функционировал верно.

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

5.3.1.4 Составление управленческой отчетности

При формировании управленческих отчетов необходимо рассмотрение следующей информации и статистики:

-  количество изменений, внедренных за период времени;

-  распределение изменений в соответствии с причинами их проведения;

-  количество успешно проведенных изменений;

-  количество возвратов в предыдущее состояние при проведении изменений;

-  количество и причины инцидентов, которые привели к изменениям;

-  количество запросов на изменение;

-  количество проанализированных внедренных изменений и количество изменений, ожидающих анализа;

-  количество отклоненных запросов на изменение;

-  изменения, ожидающие внедрения.

Эта информация используется как основа для оценки продуктивности и эффективности процесса управления изменениями.

Аудит процесса управления изменениями должен проводиться минимум раз в год.

Аудит должен включать проверку следующих элементов:

-  случайно выбранных запросов на изменение;

-  записей об изменениях;

-  анализа запросов на изменение.

5.3.2 Действия процесса управления изменениями

Процесс управления изменениями играет наблюдательную роль в тестировании всех изменений.

Запросы на изменение могут быть связаны с любой частью ИТ-инфраструктуры, любой услугой, деятельностью. Необходимо установление процедур документирования запросов на изменение.

Все принятые запросы на изменение должны регистрироваться и получать идентификационный номер.

В процессе реализации управления изменениями должны выполняться следующие действия:

-  определение причин запросов на изменение;

-  определение формы запроса на изменение;

-  определение приоритетов запросов на изменение;

-  разработка, тестирование и внедрение изменений;

-  использование программных средств управления изменениями.

5.3.2.1 Определение причин запросов на изменение

Для составления запросов на изменение должны быть определены следующие причины:

-  решение, указанное в отчете об инциденте или проблеме;

-  неудовлетворенность пользователя уровнем услуг;

-  предложение о введении или удалении учетного элемента;

-  предложение по модернизации компонентов ИТ-инфраструктуры;

-  изменение требований или содержания процессов, обеспечивающих предоставление публичных услуг;

-  нововведения или изменения в законодательстве;

-  изменение местоположения;

-  изменения в предоставляемых услугах.

5.3.2.2 Определение формы запроса на изменение

В форму запроса на изменение должны быть включены следующие элементы:

-  порядковый номер запроса на изменение с перекрестной ссылкой на номер отчета о проблеме;

-  описание и идентификация элемента, который необходимо изменить;

-  причина внесения изменения;

-  последствия в случае не внедрения изменения;

-  версия изменяемого элемента;

-  реквизиты лица, предлагающего изменение;

-  дата предложения изменения;

-  приоритет изменения;

-  оценка влияния и ресурсы;

-  рекомендации консультативного комитета по изменениям;

-  планируемое внедрение;

-  сведения о группе разработчиков изменения;

-  оценка и управление рисками;

-  статус запроса на изменение.

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

5.3.2.3 Определение приоритетов запросов на изменение

Каждому запросу на изменение должен быть присвоен приоритет, исходя из влияния проблемы и срочности, с которой требуется восстановление. При присвоении приоритета особую важность имеет оценка риска внедрения или отклонения от изменения. Для каждого приоритета должны быть определены временные рамки. Приоритеты подразделяются на:

-  срочный – кратковременная задержка рассмотрения изменения приводит к прекращению предоставления услуг или серьезным проблемам;