3.5. Примеры Пример 1 Трудовой стаж состоит из периодов работы с 15.03.1966 г. по 23.05.1967 г.; с 15.09.1970 г. по 21.05.1987 г.; с 01.01.1989 г. по 31.12.1989 г.; с 04.09.1991 г. по 14.07.1996 г.; с 15.07.1996 г. по 12.07.1998 г. и службы в армии с 27.05.1967 г. по 09.06.1969 г.Подсчитаем трудовой стаж для оценки пенсионных прав

4.4. Примеры Пример 1 Инженер Сергеев А. П., 1950 г. р., обратился за назначением трудовой пенсии по старости в марте 2010 г. В 2010 г. ему исполнилось 60 лет. Общий трудовой стаж для оценки пенсионных прав на 01.01.2002 г. составляет 32 года 5 мес 18 дней, в том числе до 1991 г. – 30 лет.

6.3. Примеры Пример 1 Менеджер по продаже Соколов В. Н. работал по трудовому договору с 01.01.2010 г.1 января 2013 г. он умирает в возрасте 25 лет. При этом у него остаются трудоспособные родители, трудоспособная жена и дочь в возрасте 3 лет. В этом случае право на получение трудовой

7.4. Примеры Пример 1 Менеджер Васильев Р. С., 60 лет. Общий трудовой стаж по трудовой книжке для оценки пенсионных прав на 01.01.2002 г. составляет 40 лет. Среднемесячный заработок за 2000–2001 гг., по данным персонифицированного учета, – 4000 руб. Рассчитаем и сравним размеры пенсий по

8.3. Примеры Пример 1 Пенсионер получает пенсию по инвалидности I группы. С 20 мая по 5 июня 2009 г. он проходил очередное переосвидетельствование в БМСЭ и был признан инвалидом III группы 3 июня 2009 г. Группа инвалидности в этом случае снизилась. Базовая часть пенсии подлежит

10.4. Примеры Пример 1 Смерть пенсионера наступила 28 января 2009 г. За пенсией вдова пенсионера обратилась в феврале 2009 г. Совместное проживание вдовы с пенсионером на день смерти не установлено.По данному пенсионному делу территориальным органом фонда были приняты

14.7. Примеры Пример 1 Кошкина В. Н., находившаяся на иждивении умершего мужа, достигла 55 лет через 3 месяца после его смерти. За назначением пенсии обратилась по истечении 1 года со дня смерти супруга.Согласно пенсионному законодательству, пенсия будет назначена со дня

17.5. Примеры Пример 1 У индивидуального предпринимателя по трудовому договору работают четыре человека: Мороз К. В. (1978 г. р.), СветловаТ. Г. (1968 г. р.), Леонова Т. Н. (1956 г. р.) и Комаров С. Н. (1952 г. р.). Предположим, ежемесячная заработная плата каждого из них составляет 7000 руб.

Примеры Рассмотрим некоторые примеры работы этой стратегии.1. 15-минутный график EUR/USD на рис. 8.8. В соответствии с правилами этой стратегии, мы видим, что EUR/USD упал и торговался ниже 20-дневной скользящей средней. Цены продолжали снижаться, двигаясь к 1,2800, которое является

Примеры Изучим несколько примеров.1. На рис. 8.22 приведен 15-минутный график USD/CAD . Общий диапазон канала составляет примерно 30 пунктов. В соответствии с нашей стратегией, мы ставим ордера на вход на 10 пунктов выше и ниже канала, т. е. на 1,2395 и 1,2349. Ордер на покупку исполнен

Примеры Рассмотрим некоторые примеры этой стратегии в действии.1. На рис. 8.25 показан дневной график EUR/USD . 27 октября 2004 г. скользящие средние EUR/USD образовали последовательный правильный порядок. Мы открываем позицию через пять свечей после начала формирования по 1,2820.

5.3.1 Обработка Инцидента.

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

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

На Рисунке 5.2 показаны процессы, происходящие в течение жизненного цикла Инцидента. В Приложении 5Д эти процессы представлены с другой точки зрения.

Рисунок 5.2 - Жизненный цикл Инцидента.

Статус Инцидента отражает его текущее положение в жизненном цикле, иногда называемое «позицией в диаграмме последовательности выполняемых действий». Каждый сотрудник должен знать все возможные статусы и их значения. Несколько примеров категорий статусов:.

■ новый;.

■ принят;.

■ определены сроки;.

■ назначен/передан специалисту;.

■ в работе (Work In Progress, WIP);.

■ ожидание;.

■ разрешен;.

■ закрыт.

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

■ обновить исторические сведения;.

■ изменить статус (например, со статуса «новый» на статус «в работе» или «ожидание»);.

■ изменить влияние на бизнес и приоритет;.

■ ввести потраченное время и затраты;.

■ отследить статус эскалации.

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

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

■ имя человека, сделавшего изменение в записи;.

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

■ что именно этот человек изменил (например, приоритет, статус, историю);.

■ почему было внесено изменение;.

■ потраченное время.

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

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

5.3.2 Первая, вторая и третья линии поддержки.

Часто подразделения и (специализированные) группы поддержки, не входящие в состав Службы Service Desk, называются группами поддержки второй или третьей линии. Они обладают более специализированными навыками, дополнительным временем или другими ресурсами для разрешения Инцидентов. Исходя из этого, Служба Service Desk называется первой линией поддержки. На Рисунке 5.3 показано, как эта терминология связана с действиями в процессе Управления инцидентами, о которых говорилось в предыдущих параграфах.

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

Рисунок 5.3 ~ Первая, вторая и третья линии поддержки.

5.3.3 Сравнение функциональной и иерархической эскалации.

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

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

«Иерархическая эскалация» может произойти в любой момент процесса разрешения, если существует вероятность того, что разрешение Инцидента не удастся завершить вовремя или оно окажется неудовлетворительным. В случае, если не хватает знаний или квалификации, иерархическая эскалация обычно производится вручную (Службой Service Desk или другим персоналом поддержки). Возможность проведения автоматической иерархической эскалации может рассматриваться после некоторого критичного периода времени, когда становится очевидным, что своевременно разрешить Инцидент не удастся. Предпочтительно, чтобы эскалация происходила задолго до истечения времени, отведенного (в SLA) на разрешение. Это позволит линейному руководству, имеющему соответствующие полномочия, принять меры по исправлению ситуации, например нанять специалистов внешнего поставщика.

5.3.4 Приоритет.

Приоритет Инцидента первоначально определяется его влиянием на бизнес и срочностью, с которой необходимо обеспечить разрешение или Обходное решение. Целевые показатели для разрешения Инцидентов или обработки запросов обычно включаются в SLA. На практике целевые показатели разрешения Инцидентов часто связаны с категориями. Примеры категорий и приоритетов, а также систем их кодирования, можно найти в Приложениях 5А и 5Б соответственно.

Службе Service Desk отводится важная роль в процессе Управления инцидентами:.

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

■ основная масса Инцидентов (возможно, до 85% при высоком уровне навыков персонала) будет разрешена Службой Service Desk;.

■ Служба Service Desk - «независимое» подразделение, которое наблюдает за ходом разрешения всех зарегистрированных Инцидентов.

Ниже приведен перечень основных действий, которые выполняются Службой Service Desk после получения уведомления об Инциденте:.

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

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

■ для дополнения записи об Инциденте на основе CMDB происходит выбор Учетных элементов (УЭ), являющихся, по сообщению, причиной Инцидента;.

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

■ оценка Инцидента и, по возможности, предоставление рекомендаций по его разрешению: часто это возможно для стандартных Инцидентов или, когда его причиной является известная Проблема/ошибка;.

■ закрытие записи об Инциденте после его успешного разрешения: добавление сведений о действиях, связанных с разрешением, и установка соответствующего кода категории;.

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

5.3.5 Связи между Инцидентами, Проблемами, Известными ошибками и Запросами на Изменение (RFC).

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

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

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

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

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

Рисунок 5.4 - Связи между Инцидентами, Проблемами, Известными ошибками и Запросами на Изменение (RFC).

Таким образом, мы имеем следующие определения:.

■ Проблема: неизвестная исходная причина одного и более Инцидентов.

■ Известная ошибка: Проблема, которая успешно диагностирована и для которой известно Обходное решение.

■ RFC: Запрос на Изменение любого компонента ИТ-инфраструктуры или любого аспекта ИТ-услуг.

Проблема может привести к множеству Инцидентов; также возможно, что Проблема не будет диагностирована до тех пор, пока не случится несколько Инцидентов в какой-нибудь период времени. Обработка Проблем значительно отличается от обработки Инцидентов и, следовательно, описана процессом Управления проблемами.

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

Когда процесс Управления инцидентами находит Обходное решение, оно будет проанализировано командой Управления проблемами, которая потом обновит соответствующую запись о Проблеме (см. Рисунок 5.5). Необходимо отметить, что соответствующая запись о Проблеме может в этот момент еще не существовать например, Обходное решение может состоять в том, чтобы отослать отчет по факсу из-за сбоя в канале связи, но записи о Проблеме по поводу этого сбоя в канале связи может еще не быть; в этом случае команда Управления проблемами должна ее создать. Итак, в процесс входят действия, когда Служба Service Desk связывает Инциденты, которые являются результатом зарегистрированной Проблемы.

Рисунок 5.5 - Обработка Обходных решений и разрешений инцидента.

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

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

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

ИНЦИДЕНТ (от лат. incidens, родительный падеж incidentis — случающийся) , случай, происшествие (обычно неприятное); столкновение, недоразумение.

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

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

Муж и жена.

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

Но! Вместо традиционной и шутливой реакции с его стороны — КТО ТАМ? Она слышит затянувшееся молчание.

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

Три коротких шага из прихожей в зал показались ей вечностью. А ее бурные фантазии успели розыграться не на шутку.

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

Жене, совсем наоборот, хотелось не просто общения, а еще и внимания и благодарности в свой адрес по-поводу ее результатов.

Вот вам две полярности, две планеты, два разных уровня пребывания сознания, два разных желания.

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

Но прежде чем я покажу выход из данной ситуции. Давайте рассмотрим еще один пример.

Начальник, подчиненная.

Ей было дано производственное задание, которое нужно было сделать к определенному сроку. В силу разных обстоятельств (а главное благодаря своему бессознательному выбору) — сроки были упущены, а задание ни сделано во — время.

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

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

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

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

Безусловно сейчас можно очень долго рассуждать по- этому поводу.

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

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

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

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

И так для начала рассмотрим причину конфликта .

Как в первом, так и во втором случае, причиной таких инцидентов стали — НЕ ОПРАВДАННЫЕ ОЖИДАНИЯ.

Да именно они являются охилесовой пятой в рассмотренных конфликтах (и не только).

Что здесь важно понять?

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

А какие программы лежат в этих словах (осмелюсь вам еще раз напомнить)?

О (ум) — ЖИД — дАН . НАД —ад -Е- ДА .

Вот и все!

Сначала мы запускаем остановку (Оум ЖИД) своей творческой энергии. А потом лелеем себя надеждой и начинаем играть в игру — пройти (НАД -Адом через ДА т.е. согласие).

Как в первом (у жены и у мужа), так и во — втором случае (у начальника и подчиненной), каждый игрок лелеял свои ожидания.

В итоге разность энергий вложенная в их ожидания вызвала взрыв (конфликт) «на макоронной» фабрике.

В задачке спрашивается, а как можно было избежать данного инцидента?

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

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

Главное было бы желание.

Однако мой ответ был бы не полным если бы я не сказала о главном.

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

Сутью такого КЛЮЧА является формирование у себя стратегического мышления или подхода. В переводе на русский язык — это означает, что перед любой встречей с кем бы то нибыло (с мужем, женой, начальником…), вы всегда заранее определяете суть своей игры (мы все здесь на Земле играем — это нужно понимать), в которой четко формулируете свой конечный результат.

Сейчас вы мне можете возразить и сказать: «Вот завернула! Это какой я еще должна (ен) определять результат при общении с мужем (женой)! Ведь каждый день замучаешься это делать!».

И тем ни менее, как подтверждает мой личный и опыт моих клиентов —

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

Поэтому мне не надо верить — это можно только проверить.

P.S. Сейчес самое благодатное время для изменения своих деструктивных программ.

Дело утопающих, дело рук самих утопающих.

С вами была Пеняйчева Любовь .

При одновременной обработке нескольких инцидентов необходимо расставлять приоритеты. Обоснованием для назначения приоритета служит уровень важности ошибки для бизнеса и для пользователя. На основе диалога с пользователем и в соответствии с положениями Соглашений об Уровнях Услуг (Service Level Agreements – SLAs) Служба Service Desk назначает приоритеты, определяющие порядок обработки инцидентов. При эскалации инцидентов на вторую, третью или более линии поддержки, тот же приоритет должен быть соблюден, но иногда он может быть скорректирован по согласованию со Службой Service Desk.

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

срочность инцидента : приемлемая задержка разрешения инцидента для пользователя или бизнес-процесса.

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

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

Рис. 4.2. Определение степени воздействия, срочности и приоритета

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

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

Таблица 4.1. Пример системы кодирования приоритетов

Эскалация

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

Различают функциональную и иерархическую эскалацию:

Функциональная эскалация (горизонтальная) – означает привлечение большего количества специалистов или предоставление дополнительных прав доступа для разрешения инцидента; при этом, возможно, происходит выход за пределы одного структурного ИТ-подразделения.

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

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

Первая, вторая и n-линия поддержки

Выше была изложена маршрутизация инцидента, или функциональная эскалация. Маршрутизация определяется требуемым уровнем знаний, полномочий и срочностью. Первой линией поддержки (называемой также поддержкой 1-го уровня) обычно является Служба Service Desk, второй линией – подразделений, осуществляющие Управление ИТ-инфраструктурой, третья – отделы разработки и архитектуры программного обеспечения, и четвертая – поставщики. Чем меньше организация, тем меньше в ней уровней эскалации. В больших организациях Руководитель Процесса Управления Инцидентами может назначить Координаторов инцидентов в соответствующих подразделениях для поддержки своей деятельности. Например, координаторы могут играть роль интерфейса между процессной деятельностью и линейными организационными подразделениями. Каждый из них координирует деятельность собственных групп поддержки. Процедура эскалации графически представлена на рис. 4.3.

Рис. 4.3. Эскалация инцидента (источник: OGC)

Целью Процесса Управления Инцидентами является скорейшее восстановление нормального Уровня Услуг, определенного в Соглашении об Уровне Услуг (Service Level Agreement – SLA), с минимальными возможными потерями для бизнес-деятельности организации и пользователей. Кроме того, Процесс Управления Инцидентами должен вести точную регистрацию инцидентов для оценки и совершенствования процесса и предоставления необходимой информации для других процессов.

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

Для бизнеса в целом:

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

Повышение производительности работы пользователей;

Независимый, ориентированный на потребности заказчика мониторинг инцидентов;

Доступность объективной информации о соответствии предоставляемых услуг согласованным договоренностям (SLA).

Для ИТ-организации:

Улучшенный мониторинг, позволяющий проводить точное сопоставление уровня производительности ИТ-систем с соглашениями (SLA);

Эффективное руководство и мониторинг выполнения соглашений (SLA) на основе достоверной информации;

Эффективное использование персонала;

Предотвращение потерь инцидентов и Запросов на Обслуживание или их неправильной регистрации;

Повышение точности информации в Конфигурационной Базе Данных (Configuration Management Database – CMDB) за счет ее проверки при регистрации инцидентов в привязке к Конфигурационным Единицам (Configuration Item – CI);

Повышение удовлетворенности пользователей и заказчиков.

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

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

Пользователи могут перенаправляться к одним и тем же специалистам «по кругу» без успешного разрешения инцидента;

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

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

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

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

На рис. 4.4 показаны входы и выходы процесса, а также виды деятельности, которые охватывает этот процесс.

Рис. 4.4. Положение Процесса Управления Инцидентами

4.3.1. Входы процесса

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

4.3.2. Управление конфигурациями

Конфигурационная База Данных (Configuration Management Database - CMDB) играет важную роль в Управлении Инцидентами, так как она определяет связь между ресурсами, услугами, пользователями и Уровнями Услуг (сервисов). Например, Управление Конфигурациями показывает, кто является ответственным за компонент инфраструктуры, что делает возможным более эффективное распределение инцидентов по группам специалистов. Кроме того, эта база данных помогает решать оперативные вопросы, например, перенаправление очереди печати или переключение пользователя на другой сервер. При регистрации инцидента в регистрационные данные добавляется связь (link) с соответствующей Конфигурационной Единицей (Configuration Item – CI), позволяющая предоставить более подробную информацию об источнике ошибки. В случае необходимости может быть обновлен статус соответствующей компоненты в CMDB.

4.3.3. Управление Проблемами

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

4.3.4. Управление Изменениями

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

4.3.5. Управление Уровнем Услуг

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

4.3.6. Управление Доступностью

Для определения показателей доступности услуг Процесс Управления Доступностью использует регистрационные данные об инцидентах и данные мониторинга статуса, предоставляемые Процессом Управления Конфигурациями. Аналогично Конфигурационной Единице (CI) в Конфигурационной Базе Данных (CMDB), сервису (услуге) может быть также назначен статус «не работает» . Это может быть использовано для проверки действительных показателей доступности услуги и времени реагирования поставщика. При осуществлении такой проверки необходима фиксация времени действий, произошедших в процессе обработки инцидента, от момента обнаружения и до закрытия.

4.3.7. Управление мощностями

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

Ни рис. 4.5. показаны этапы процесса:

Рис. 4.5. Процесс Управления Инцидентами

Прием и регистрация инцидента (Acceptance and Recording) – принимается сообщение и создается запись об инциденте.

Классификация и начальная поддержка (Classification and Initial Support) – присваиваются тип, статус, степень воздействия, срочность, приоритет инцидента, SLA и т.п. Пользователю может быть предложено возможное решение, даже если оно только временное.

Если вызов касается Запроса на Обслуживание (Service Request) , то инициируется соответствующая процедура.

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

Расследование и диагностика (Investigation and Diagnosis) – при отсутствии известного решения производится исследование инцидента с целью как можно быстрее восстановить нормальную работу.

Решение и восстановление (Resolution and Recovery) – если решение найдено, то работа может быть восстановлена.

Закрытие (Closure) – с пользователем связываются, чтобы он подтвердил согласие с предложенным решением, после чего инцидент может быть закрыт.

Мониторинг хода работ и отслеживание (Progress monitoring and Tracking) – весь цикл обработки инцидента контролируется, и если инцидент не может быть разрешен вовремя, производится эскалация.

4.4.1. Прием и регистрация

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

Трудно произвести точную регистрацию информации об инциденте, если это не сделано сразу;

Мониторинг хода работ по решению инцидента возможен, только если инцидент зарегистрирован;

Зарегистрированные инциденты помогают при диагностике новых инцидентов;

Управление Проблемами может использовать зарегистрированные инциденты при работе над поиском корневых причин;

Легче определить степень воздействия, если все сообщения (звонки) зарегистрированы;

Без регистрации инцидентов невозможно контролировать исполнение договоренностей (SLA);

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

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

Обнаружен пользователем : он докладывает об инциденте в Службу Service Desk.

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

Обнаружен сотрудником Службы Service Desk : сотрудник производит регистрацию инцидента.

Обнаружен кем-либо в другом подразделении ИТ : этот специалист регистрирует инцидент в системе регистрации инцидентов или докладывает о нем в Службу Service Desk.

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

Если есть (и они касаются того же инцидента) , информация об инциденте обновляется или же инцидент регистрируется отдельно и устанавливается связь (привязка) к главному инциденту; при необходимости изменяется степень воздействия и приоритет, и добавляется информация о новом пользователе.

Если нет (отличается от открытого инцидента) , производится регистрация нового инцидента.

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

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

Назначение номера инцидента : в большинстве случаев система автоматически назначает новый (уникальный) номер инцидента. Часто этот номер сообщается пользователю, чтобы он мог ссылаться на него при дальнейших контактах.

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

Запись дополнительной информации об инциденте : добавляется информация, например, из скрипта (script) или процедуры опроса или из Конфигурационной Базы Данных – CMDB (обычно на основе взаимоотношений Конфигурационных Единиц, определенных в CMDB).

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

4.4.2. Классификация

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

Центральная процессинговая система – подсистема доступа, центральный сервер, приложение.

Сеть – маршрутизаторы, сегменты, концентратор (hub), IP-адреса.

Рабочая станция – монитор, сетевая карта, дисковод, клавиатура.

Использование и функциональность – услуга (сервис), возможности системы, доступность, резервное копирование (back-up), документация.

Организация и процедуры – заказ, запрос, поддержка, оповещение (коммуникации).

Запрос на Обслуживание – запрос пользователя в Службу Service Desk на поддержку, предоставление информации, документации или оказание консультации. Это может быть выделено в отдельную процедуру или обработано таким же образом, как реальный инцидент.

Приоритет

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

Приоритет = Срочность х Степень воздействия.

Услуги (сервисы)

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

Группа поддержки

Если Служба Service Desk не может разрешить инцидент незамедлительно, то определяется группа поддержки, которая будет заниматься разрешением инцидента. Основой для распределения (маршрутизации) инцидентов часто является информация о категориях. При определении категорий может потребоваться рассмотрение структуры групп поддержки. Правильное распределение инцидентов имеет существенное значение для эффективности Процесса Управления Инцидентами. Поэтому одним из ключевых показателей эффективности (KPI) Процесса Управления Инцидентами может быть число неправильно распределенных обращений.

Сроки решения

С учетом приоритета и соглашения SLA пользователь информируется о максимальном расчетном времени разрешения инцидента. Эти сроки также фиксируются в системе.

Идентификационный номер инцидента

Абонент информируется о номере инцидента для его точной идентификации при последующих обращениях.

Статус

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

Запланирован;

Назначен;

Активный;

Отложен;

Разрешен;

4.4.3. Привязка (сопоставление)

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

4.4.4. Расследование и диагностика

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

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

4.4.5. Решение и восстановление

После успешного завершения анализа и разрешения инцидента сотрудник записывает решение в систему. В некоторых случаях необходимо направить Запрос на Изменение (RFC) в Процесс Управления Изменениями. В наихудшем случае, если не найдено никакого решения, инцидент остается открытым.

4.4.6. Закрытие

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

4.4.7. Мониторинг хода решения и отслеживание

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

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

Руководителю Процесса Управления Инцидентами отчет необходим для :

Идентификации недостающих звеньев процесса;

Идентификации нарушений исполнения соглашений об Уровне Услуг (SLA);

Отслеживания хода выполнения процесса;

Определения тенденций развития.

Руководство Линейными ИТ-подразделениями – отчет для руководства группы поддержки; он также может быть полезен в Управлении ИТ-подразделениями. Отчет должен содержать следующую информацию:

Прогресс в решении инцидентов;

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

Управления Уровнем Сервисов (Услуг) – отчет должен, прежде всего, содержать информацию о качестве предоставляемых услуг. Руководитель Процесса Управления Уровнем Услуг должен получать всю информацию, необходимую для составления Отчетов об Уровне Услуг перед заказчиками. Отчеты для заказчиков должны предоставлять информацию о том, выполняются ли соглашения в отношении Уровня Сервисов (услуг) в рамках Процесса Управления Инцидентами.

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

Число обнаруженных и зарегистрированных инцидентов;

Число разрешенных инцидентов, с разделением по времени разрешения;

Статус и число неразрешенных инцидентов;

Инциденты с разбивкой по периодам возникновения, группам заказчика, группам поддержки и временем разрешения в соответствии с соглашением (SLA);

4.5.1. Критические факторы успеха

Для успешного Управления Инцидентами необходимо следующее:

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

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

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

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

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

Среднее число инцидентов, разрешенных в рамках соглашений (SLA);

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

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

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

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

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

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

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

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

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

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

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

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

Развитие и сопровождение системы Управления Инцидентами.

Персонал групп поддержки

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

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

4.6.1. Затраты

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

4.6.2. Проблемы

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

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

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

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

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

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

Примечания:

Под «цепочкой» понимается цепь создания прибавочной стоимости. – Прим. ред.

В литературе по ITIL понятие «функция» ассоциировано с вертикальным (линейным) подразделением организации, выполняющим соответствующие функциональные обязанности и фактически является его синонимом. – Прим. ред.

Service Request.

Request for Change (RFC).

Configuration Item (CI).

Key Performance Indicators – KPI.

Performance Indicators.

Effectiveness and Efficiency.

Т.е. программного обеспечения. – Прим. ред.

Рекомендуем почитать

Подросток

Расследование инцидента иб по горячим следам

Мама с ребенком

Жизненный цикл программных систем

Лайфстайл

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

Недвижимость

Разделение рабочего дня части производится

Способы заработка 

Название фирмы по нумерологии

Способы заработка 

Образец резюме мерчандайзера