назад Оглавление вперед


[Старт] [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14] [15] [16] [17] [ 18 ] [19] [20] [21] [22] [23] [24] [25] [26] [27] [28] [29] [30] [31] [32] [33] [34] [35] [36] [37] [38] [39] [40] [41] [42] [43] [44] [45] [46] [47] [48] [49] [50] [51] [52] [53] [54] [55] [56] [57] [58] [59] [60] [61] [62] [63] [64] [65] [66] [67] [68] [69] [70] [71] [72]


18

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

•Соответствуюп(ую автоматизированную систему регистрации, отслеживания и мониторинга инцидентов.

Дополнительно необходимо тесное взаимодействие с Процессом Управления Уровнем Сервисов (Услуг) для определения требуемых приоритетов и времени разренгения инцидентов.

4.5.2.Показатели эффективности

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

•обн1ее количество инцидентов;

•среднее время разрешения инцидентов;

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

•среднее число и1пп1дентов, разреше1И1Ых в рамках соглашений (SLA);

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

•средняя стоимость поддержки на инцидент;

•число решенных инцидентов иа одно рабочее место или на одного сотрудника службы Service Desk;

•инциденты, penieHHbie без посещения пользователя (удаленно);

•число (или процент) и1ищдентоп с первоначально некорректной классификацией;

•число (или процент) инцидентов, неправильно распределенных в группы поддержки.

4.5.3.Функции и роли

Реализация процессов проходит в горизонтальной плоскости через иерархическую CTpyicrypy организации. Это возможно только при четком определении ответственности и полномочий, связанных с реализащтей процессов. Для повышения гибкости может быть использован ролевой подход (т.е. определение ролей). В небольших орга1п-1зациях или в целях снижения общих расходов возможно комбинирование ролей, например, совмещение ролей Руководителя Процессов Управления Изменениями и Управления Конфигурациями.

Руководитель Процесса Управления Инцидентами

Во многих организациях роль Руководителя Управления Инцидентами играет менеджер Службы Service Desk. В сферу ответственности Руководителя Процесса Управления Инцидентами включается следующее:

•мониторинг эффективности и рациональности работы процесса;

•контроль работы групп поддержки;

•составление рекомендаций по соверптенствованию работы процесса;

•развитие и сопровождение системы Управления Инцидентами. Персонал групп ноддержки

•Первая линия поддержки несет ответственность за регистрацию, классификацию, сопоставление (привязку), распределение но rpyiHiaM поддерлски, разрешение и закрытие инцидентов.

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

Knowledge Base.

° Performance indicators.

Effectiveness and efficiency.



т. е. nporpawAHoro обеспечения. - Прим. ред. Commitment.

4.6. Затраты и проблемы

4.6.1.Затраты

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

4.6.2.Проблемы

При внедрении Управления Инцидентами могут возникнуть следуюнп1е проблемы:

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

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

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

•Отсутствие Каталога Услуг и Соглашений об Уровне Сервисов (SLA) - если поддерживаемые услуги и продукты недостаточно точ}ю определены, тогда специалистам, вовлеченным в Управление Инцидентами, бывает трудно обоснованно отказать пользователям в помощи.

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



Управление Проблемами 5.1. Введение

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

Для выясне1П1я корневых прич1П1 возникновения как суитествуюищх, так и потенциальных ошибок в иредоставлении услуг, в рамках Процесса Управления Проблемами производится изучеине инфраструктуры и имеюнщхся регистрациотп1ых данных, включая базу данных инцидентов. Такие исследования необходимы из-за слоясного и расиределенного характе[)а инфраструктуры, когда связи между инцидентами ие всегда бывают очевидными. Например, причиной проблемы могут стать сразу несколько огиибок, и в то же время несколько проблем могут быть связаны с одной и той же отпиб-Koii. Вначале надо определи ть причину возникновения проблемы. После того, как корневая причина определена, проблема переходит в разряд известных отпибок и для устранения этой причины можно направить Запрос на Изменение. Но даже после этого известные отппбки будут отслеживаться и контролироваться в рамках Процесса Управления Проблемами. Поэтому следует вести регистрацию всех иденгифннирова1Н1ых известных ошибок, их симптомов и имею11и1хся решений.

5.1.1. Определение - «проблема» и «известная ошибка»

На рис 5.1 показаны взаимосвязи между проблемой, известной отнттбкой и Запросом на Изменение и даны определения этих терминов.

Проблема

Характеризует нежелательную ситуацию и сигнализирует о неизвестной корневой причине ОАюго или нескольких у*;е произошедших или возможных в будущем инцидентов

Известная ошибка

Известная аиибка - это проблема, корневая причина которой уже установлена

Запрос не изменение:

Запрос, предлагающий произвести изменение, напри.*лер устранить извеаную ошибку

Рис 5.1. Отношения между проблеллами и известными ошибкалли (источник: OGC)

5.1.2. Взаимоотношения с Процессом Управления Инцидентами

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

Request foe Change - RFC.

Quick hxes - быстрые исправления, бьютрые решения или «заплатки», т. е. решения, позволяюцие быстро устранить инцидент, но не устраня-кхцие ошибку

[Старт] [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14] [15] [16] [17] [ 18 ] [19] [20] [21] [22] [23] [24] [25] [26] [27] [28] [29] [30] [31] [32] [33] [34] [35] [36] [37] [38] [39] [40] [41] [42] [43] [44] [45] [46] [47] [48] [49] [50] [51] [52] [53] [54] [55] [56] [57] [58] [59] [60] [61] [62] [63] [64] [65] [66] [67] [68] [69] [70] [71] [72]