Обзор решений моделирования бизнес-процессов управления ИT сервисами

Владелец процесса, руководство ИТ-отдела, владелец процесса SLA, члены команды, владелец процесса SIP.

Процент своевременно проведенных проверок и аудитов в сфере ИТ.

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

Внутренние проверки и аудиты позволяют нам выявить недостатки процесса.

Владелец процесса, руководство ИТ-отдела, владелец процесса SLA, члены команды, владелец процесса SIP.

Число выявленных рисков (предостережения и новые угрозы) по проекту ИТ.

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

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

Владелец процесса, руководство ИТ-отдела, владелец процесса SLA, члены команды, владелец процесса SIP.

Процент внешних договоров, где явно оговорены вопросы информационной безопасности

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

Уменьшить вероятность появления дополнительных рисков за счет внешних договоров.

Владелец процесса, руководство ИТ-отдела, владелец процесса SLA, члены команды, владелец процесса SIP.

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

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

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

Владелец процесса, руководство ИТ-отдела, владелец процесса SLA, члены команды, владелец процесса SIP.

Число изменений, которые были по соображениям информационной безопасности отменены (и система возвращена в исходное состояние)

Данная метрика отображает количество изменений, которые по причине информационной безопасности были отклонены. Изменения были плохо спланированы.

Предотвратить возможность преднамеренной атаки.

Владелец процесса, руководство ИТ-отдела, владелец процесса SLA, члены команды, владелец процесса SIP.

Скорость установки патчей, связанных с информационной безопасностью

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

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

Владелец процесса, руководство ИТ-отдела, владелец процесса SLA, члены команды, владелец процесса SIP

Документирование процесса

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

· Соглашение об уровне услуг (OLA), соглашение об уровне услуг в отличии от предыдущего заключается между поставщиком и каким-либо департаментом, между различными службами внутри компании. Таким образом соглашение об уровне услуг дополняет соглашение об уровне сервиса.

· Политика управления рисками информационной безопасности, информация о том, как вести себя в случае, если появляются проблемы, сбои и прочие риски;

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

2.5 Процесс управления бюджетированием и учетом затрат

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

Описание процесса

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

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

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

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

Задачи: правильно проанализировать и запланировать затраты на проект, а также просчитать возможные отклонения от плана.

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

Окружение процесса

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

· Управление подрядчиками - оплата за выполненные работы приглашенному персоналу.

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

· Управление релизами включает затраты на персонал, создание, поддержку и распространение релизов, а также затраты на программные средства.

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

· Управление мощностями - прямая взаимосвязь мощностей ИТ-сервисов и финансовых ресурсов. Приобретение дополнительных мощностей и увеличение доступности стоит определенных материальных ресурсов.

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

Метрики процесса бюджетирования и учета затрат

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

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

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

управление процесс бизнес моделирование

Владелец процесса: руководитель ИТ.

Метрика	Описание	Задача метрики	Аудитория
Процент учитываемых расходов на ИТ	Доля расходов, которые приходятся на область ИT при распределении бюджета.	Управлять затратами на ИТ - проекты и инфраструктуру, обеспечивать стабильную основу для решений, которые касаются ИТ-сферы, путем определения и учета затрат на предоставление услуг, а также обоснованного возмещения издержек, если это возможно.	Руководитель ИТ
Процент затрат на оплату труда в сфере ИT.	Доля выплат, приходящихся на сотрудников из ИT структуры.	Определение и анализ затрат на сферу ИT, относительно выплат на остальных сотрудников.	Владелец процесса, руководство ИТ, владелец процесса SLA, бизнес-клиент, члены команды, владелец процесса SIP.
Задержки в создании финансового отчета на ИT проект.	Данная метрика показывает, на сколько времени запоздал финансовый отчет.	Использование финансового отчета для оценки прогресса.	Владелец процесса, руководство ИТ, владелец процесса SLA, бизнес-клиент, члены команды, владелец процесса SIP.
Степень достоверности (в процентах) финансового прогноза на предыдущий квартал в сфере ИT.	Отношение сделанного ранее прогноза к фактическим данным.	Привести достоверность финансового прогноза к идеальному.	Владелец процесса, руководство ИТ, владелец процесса SLA, бизнес-клиент, члены команды, владелец процесса SIP.
Совокупная стоимость владения проекта	Метрика показывает, в какую сумму обходится компании владение информационными технологиями. ТСО включает все финансовые расходы, в том числе заработную плату, затраты на амортизацию, оборудование и инфраструктуру.	Снизить совокупную стоимость владения.	Владелец процесса, руководство ИТ, владелец процесса SLA, бизнес-клиент, члены команды, владелец процесса SIP.
Число жалоб, касающихся затрат на ИТ	Если возникают жалобы по затратам, финансовая служба обязана предоставить обоснование или финансовый отчет, где будет указано чем вызваны те или иные затраты, они к тому же могут быть неубедительными и необоснованными. Это означает, что принципы управления финансами требуют пересмотра.	Обосновать затраты на выполнение проекта	Владелец процесса, руководство ИТ, владелец процесса SLA, бизнес-клиент, члены команды, владелец процесса SIP.
Стоимость отклонений от плана выполнения проекта	В затратах на проект, важно учитывать сколько компания потеряет, в случае сбоя или приостановки работы.	Подсчет затрат, которые понесет компания в связи с непредвиденными обстоятельствами	Владелец процесса, руководство ИТ, бизнес-клиент, члены команды.

Документирование процесса

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

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

• Статьи затрат (процессы и услуги, на которые необходимо производить выплаты);

• Отчеты по затратам (месячный, декадный, квартальный отчет о затратах для использования его в последующем);

• Смета-заявка - совокупные фактические затраты по проекту, вместе с отчетами по отдельным периодам, чтобы можно было проанализировать, когда произошла задержка (если была);

• Сводный реестр участников проекта и внешних сотрудников;

• Акты обследования оборудования;

• Сметные расчеты (в них указываются статьи затрат и величину затрат);

• Заключения отделов по возможным рискам и затратам;

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

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

Описание процесса

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

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

Окружение процесса

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

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

· управление релизами

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

· управление уровнем услуг

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

Метрики процесса управления изменениями

ѕ Количество изменений;

ѕ Количество срочных изменений;

ѕ Количество прерываний работы системы, вследствие изменений;

ѕ Срок выполнения изменения;

ѕ Количество изменений, обработанных за месяц [штуки];

ѕ Доля изменений, возвращённых на повторное оформление в результате проверки менеджером процесса [%].

Документирование процесса

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

Сводная таблица KPI - Подготовка данных для контроля эффективности внедрения изменений.

Срочный RFC - Срочный запрос может быть исполнен до заведения RFC в случае устного одобрения со стороны менеджера процесса CHG.

Заявка на ИТ-услуги.

2.7 Процесс управления инцидентами

Описание процесса

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

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

Цели

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

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

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

Требования

Благодаря процессу управлению инцидентами выполняется следующее:

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

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

- клиентоориентированный мониторинг инцидентов;

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

- согласованным договоренностям (SLA).

Задачи

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

1. выявление и регистрация инцидентов;

2. классификация и начальная поддержка;

3. исследование и диагностика;

4. решение и восстановление;

5. закрытие;

6. владение, мониторинг, отслеживание и связь.

Принципы

ь Координация между пользователями и специалистами по решению инцидентов;

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

ь Удовлетворенность пользователей, обеспечивающаяся на всех этапах решения инцидентов;

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

ь Все инциденты управляются, а их данные сохраняются в единой базе данных;

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

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

ь Все записи инцидентов по мере возможности должны иметь общие формат и набор информационных полей;

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

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

Существует несколько классификаций инцидентов:

a) Категоризация, при которой инцидентам присваивается категория и подкатегория, с учетом предполагаемого источника инцидента или соответствующей группы поддержки:

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

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

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

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

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

запрос на обслуживание -- запрос пользователя в службу Service Desk на поддержку, предоставление информации, документации или оказание консультации.

b) Приоритезация, присвоение номера, определяющего срочность и степень воздействия.

c) Распределение по услугам и сервисам на основании договоренной об уровне услуг SLA.

d) Распределение на группу поддержки по категории. При правильном распределении инцидента процесс управления инцидентами показывает высокие показатели эффективности (KPI).

e) Сроки решения.

f) Статус инцидента.

Функции

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

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

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

ь предотвращение потерь на этапе получения сведений об инцидентах и запросах на обслуживание при их неправильной регистрации;

ь повышение точности информации в конфигурационной базе данных (Configuration Management Database -- CMDB) за счет ее проверки при регистрации инцидентов в привязке к конфигурационным единицам (Configuration Item -- CI);

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

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

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

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

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

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

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

· увеличенные трудозатраты на решение проблем.

Окружение процесса

Процесс	Взаимосвязь
Управление конфигурациями	Определяет связь между ресурсами, услугами, пользователями и Уровнями Услуг (сервисов). При регистрации инцидента в регистрационные данные добавляется связь (link) с соответствующей Конфигурационной Единицей (Configuration Item -- CI), позволяющая предоставить более подробную информацию об источнике ошибки
Управление проблемами	Позволяет облегчить поиск корневых причин посредством качественной регистрации инцидента
Управление изменениями	Предоставляет информацию о запланированных изменениях и их статусах
Управление уровнем услуг	Контролирует выполнение договоренностей (соглашений - SLA) с заказчиком о предоставляемой ему поддержке
Управление доступностью	Показатель доступности предоставляемых услуг и сервисов
Управление мощностями	Получает информацию об инцидентах, связанных с функционированием самих ИТ?систем

Метрики процесса управления инцидентами

Метрика	Описание	Задача	Аудитория
Процент решаемых инцидентов при обработке на первой линии технической поддержки	Расчитывается количество инцидентов, которые не требуют эскалации на вторую линию поддержки	Измерение параметров, путем сравнения в БД службы Service Desk известных ошибок, поставляемых управлением проблемами, при котором количество инцидентов, устраняемых первой линией поддержки вырастет	Владелец бизнес-процесса, руководство ИТ-отдела, владелец процесса SLA, бизнес-клиент, члены команды, владелец процесса SIP (Session Initiation Protocol)
Время обработки инцидента до момента эскалации	Показатель эффективности, позволяющий обеспечивать равновесие с метрикой степени удовлетворенности клиента, поскольку обслуживание заявки должно длиться столько, сколько потребуется для удовлетворения запроса пользователя по решению проблемы	Служба Service Desk должна обеспечивать эффективную обработку заявки, посредством оптимального времени обработки заявки	Владелец бизнес-процесса, руководство ИТ-отдела, владелец процесса SLA, бизнес-клиент, члены команды, владелец процесса SIP (Session Initiation Protocol)
Процент инцидентов, некорректно назначенных на сотрудников службы поддержки	Измеряется путем проверки истории заявок, имеющих путь с перенаправлением	Снижение переназначения заявок, замедляющее решение и снижающее эффективность работы команд путем действенных сценариев обработки обращения, обучения, инструментария и соответствующих процессов	Владелец бизнес-процесса, руководство ИТ-отдела, владелец процесса SLA, бизнес-клиент, члены команды, владелец процесса SIP (Session Initiation Protocol)
Процент инцидентов, решенных в течение заданного времени согласно приоритету	При поступлении заявки в службу Service Desk, ей назначается определенное время обработки в зависимости от SLA службы и приоритета заявки, т.е. таким образом показывается показатель частоты достижения результата	Оценка показателя эффективности выполнения SLA службой Service Desk	Владелец бизнес-процесса, руководство ИТ-отдела, владелец процесса SLA, бизнес-клиент, члены команды, владелец процесса SIP (Session Initiation Protocol)
Среднее время ответа второго уровня поддержки (минуты)	Время между передачей заявки на второй уровень поддержки и ее принятием, т.е. показатель эффективности второго уровня поддержки	При передаче заявок на второй уровень возникает угроза несоблюдения сроков, оговоренных в SLA. Отслеживается время реагирования и обеспечивается эффективность приема заявок	Владелец бизнес-процесса, руководство ИТ-отдела, владелец процесса SLA, бизнес-клиент, члены команды, владелец процесса SIP (Session Initiation Protocol)
Среднее время решения инцидентов (минуты)	Общая эффективность процесса управления инцидентами	Измеряется продолжительность решения инцидента с момента открытия заявки до момента ее решения, при этом фиксируются все стадии обработки заявки	Владелец бизнес-процесса, руководство ИТ-отдела, владелец процесса SLA, бизнес-клиент, члены команды, владелец процесса SIP (Session Initiation Protocol)
Процент переназначенных инцидентов	Оценка масштабов проблемы переназначения инцидентов другим командам, помогающим в решении проблемы, позволяющая усовершенствовать процессы и улучшить информационное наполнение базы данных по известным ошибкам	Измеряется число инцидентов, более одного раза назначенных на ресурс второго или третьего уровня (или группу решения)	Владелец бизнес-процесса, руководство ИТ-отдела, владелец процесса SLA, бизнес-клиент, члены команды, владелец процесса SIP (Session Initiation Protocol)
Процент неправильно классифицированных инцидентов	Количество инцидентов, которым при первоначальном присвоении категории были неправильно описаны или классифицированы. Правильная классификация позволяет ускорить решение проблем. Показатель характеризует эффективность сценария получения информации у клиентов, уровень подготовки персонала центра обработки вызовов и качество поддерживающеи? среды (например, CMDB)	Обеспечение оценки правильности выявления и регистрации инцидентов. В процессе регистрации каждои? заявки назначается категория, облегчающая ее обработку и последующии? анализ. Когда заявка закрывается, в соответствующеи? записи указывается ее настоящая категория. Метрика показывает, сколько раз две категории не совпали	Владелец бизнес-процесса, руководство ИТ-отдела, владелец процесса SLA, бизнес-клиент, члены команды, владелец процесса SIP (Session Initiation Protocol)
Процент обращении?, поступивших к специалистам службы поддержки «напрямую», минуя первыи? уровень	Частота обращении? клиентов непосредственно на второи? или третии? уровень поддержки. Измеряется путем подсчета поступивших заявок	Эффективное предоставление ИТ-услуг	Владелец бизнес-процесса, руководство ИТ-отдела, владелец процесса SLA, бизнес-клиент, члены команды, владелец процесса SIP (Session Initiation Protocol)
Степень удовлетворенности клиентов	Служит противовесом для других метрик. Если заявки закрываются слишком быстро или обслуживаются слишком долго, то независимо от того, что говорят внутрифирменные метрики, степень удовлетворенности клиентов начнет снижаться и данная метрика это покажет	Обеспечивает уровень удовлетворенности клиентов посредством проставления оценки от клиента	Владелец бизнес-процесса, руководство ИТ-отдела, владелец процесса SLA, бизнес-клиент, члены команды, владелец процесса SIP (Session Initiation Protocol)
Процент звонков, являющихся запросами на оказание услуг	Процент звонков, которые представляют собои? запросы на обслуживание, а не обращения по поводу инцидентов (или по иным причинам)	Показать, сколько в состоянии сделать для решения инцидентов процесс управления инцидентами и какои? для этого нужен объем дополнительнои? работы. Метрика отражает эффективность работы групп решения	Владелец бизнес-процесса, руководство ИТ-отдела, владелец процесса SLA, бизнес-клиент, члены команды, владелец процесса SIP (Session Initiation Protocol)
Процент инцидентов, правильно решенных с первого раза (правильное решение с первого раза)	Процент инцидентов, решенных с первои? попытки. Это значит, что не требуется ни повторное открытие того же инцидента, ни открытие нового инцидента, связанного с тем же событием	Показать, в какои? степени процесс управления инцидентами деи?ствует проактивно и какова его эффективность в решении инцидентов	Владелец бизнес-процесса, руководство ИТ-отдела, владелец процесса SLA, бизнес-клиент, члены команды, владелец процесса SIP (Session Initiation Protocol)
Процент инцидентов, решенных проактивно	Процент инцидентов, которые были решены до того, как клиенты сообщили об ошибке (нужна тесная связь с мониторингом систем и приложении?)	Решение инцидентов (обнаруженных по событиям, зафиксированным инструментами мониторинга) до того, как у пользователя возникли проблемы	Владелец бизнес-процесса, руководство ИТ-отдела, владелец процесса SLA, бизнес-клиент, члены команды, владелец процесса SIP (Session Initiation Protocol)

Документирование процесса

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

· Отчеты по инцидентам и запросам на обслуживание,

· Отчеты по разрешенным инцидентам,

· Сбор статистических сведений по инцидентам в аналитических справках,

· Хранилище баз данных по известным инцидентам;

· Отчеты по нерешенным инцидентам;

· Статистика по новым инцидентам и проценту влияния на систему или предоставление ИТ-услуги.

Рекомендации по применению процесса управления инцидентами

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

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

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

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

Описание процесса

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

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

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

1. Неправильная сетевая конфигурация компьютера;

2. Средство мониторинга неверно определяет статус канала в момент занятости маршрутизатора.

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

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

Управление проблемами включает:

1 Контроль проблем;

2 Контроль ошибок;

3 Предотвращение проблем;

4 Анализ основных проблем;

5 Контроль проблем.

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

· идентификация и регистрация;

· классификация и определение приоритетов;

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

· мониторинг ошибок.

Контроль ошибок обеспечивает исправление проблем за счет следующих действий:

1. Идентификация и регистрация известных ошибок;

2. Оценка способов устранения и расстановка приоритетов;

3. Регистрация по временному обходу ошибки в средствах службы поддержки;

4. Закрытие известных ошибок путем осуществления исправлений;

5. Мониторинг известных ошибок для определения необходимости в изменении приоритетов.

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

Требования

· существующие и регулярно возникающие ошибки идентифицированы, задокументированы и отслеживаются;

· симптомы ошибок, постоянные или временные решения документируются;

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

· предотвращается возникновение новых инцидентов;

· создаются отчеты о качестве работы ИТ-инфраструктуры и протекания самого процесса.

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

Задачи

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

Выделяются следующие задачи процесса:

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

ь повышение производительности труда пользователей за счет улучшения качества ИТ-услуг;

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

ь улучшение репутации ИТ?услуг в результате улучшения стабильности услуги или сервиса;

ь совершенствование знаний в области управления, эффективное обучение персонала и хранение всех ключевых данных;

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

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

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

Функции

· контроль проблем: определение и исследование проблем;

· контроль ошибок: отслеживание известных ошибок и подача запросов на изменения (RFC);

· проактивное управление проблемами: предотвращение инцидентов путем совершенствования ИТ-инфраструктуры;

· предоставление информации: отчеты по серьезным проблемам и достигнутым результатам.

Окружение процесса

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

Метрики процесса управления проблемами

Метрика	Описание	Задача метрики	Аудитория
Число решенных проблем	Мера активности, а также эффективности.	Сбор сведений о решенных проблемах путем оценки реакции на нее и быстроты принятия решения	Владелец процесса, руководство ИТ, владелец процесса SLA, бизнес-клиент, члены команды, владелец процесса SIP.
Число инцидентов, разрешенных при помощи базы данных, где описано решение аналогичных задач	Устранение инцидентов с помощью решений, зарегистрированных в соответствующих базах данных, экономия времени и трудозатрат, сохраняя высокий уровень обслуживания клиентов.	База данных с описанием разрешения проблем является главным каналом взаимодействия между процессами управления проблемами и инцидентами. Если ее правильно обслуживать и вести так, чтобы ею было легко пользоваться, то решение инцидентов и проблем не только ускорится, но будет возможно их полная локализация	Владелец процесса, руководство ИТ, владелец процесса SLA, бизнес-клиент, члены команды, владелец процесса SIP.
Общее число инцидентов	Инциденты могут быть вызваны проблемами -- если устранить проблемы, количество инцидентов уменьшится.	Уменьшение данного показателя	Владелец процесса, руководство ИТ, владелец процесса SLA, бизнес-клиент, члены команды, владелец процесса SIP.
Общее время неработоспособности пользователей	Метрика непосредственно связана с клиентами и показывает степень негативного влияния нерешенных проблем на бизнес.	Фактически показатель доступности, он позволяет оценить и эффективность процесса управления проблемами: если проблемы решаются быстро и эффективно, уровень простоев у пользователей снижается	Владелец процесса, руководство ИТ, владелец процесса SLA, бизнес-клиент, члены команды, владелец процесса SIP.
Число RFC, инициированных процессом управления проблемами	Количество поданных RFC.	Оценка результатов процесса	Владелец процесса, руководство ИТ, владелец процесса SLA, бизнес-клиент, члены команды, владелец процесса SIP.
Среднее число открытых проблем	Нагрузка на техническую поддержку	Число открытых проблем отражает текущую нагрузку процесса управления проблемами. Важно отслеживать этот показатель в сравнении с числом решенных проблем. Если он слишком высок, эффективность предоставления услуг на должном уровне бизнесу находится под угрозой.	Владелец процесса, руководство ИТ, владелец процесса SLA, бизнес-клиент, члены команды, владелец процесса SIP.
Среднее время закрытия проблемы	Оценка реакции на проблему и загруженность процесса	Если со временем среднее время решения проблемы снижается, это говорит об улучшении используемого инструментария и функционирования процессов. Рост показателя служит заблаговременным предупреждением о том, что управлению проблемами не хватает ресурсов.	Владелец процесса, руководство ИТ, владелец процесса SLA, бизнес-клиент, члены команды, владелец процесса SIP.
Процент инцидентов, которые не удалось связать с проблемой	Инциденты, которые еще не были исследованы в рамках процесса управления проблемами.	Установление причинно-следственная связи, окончательное разрешение ситуации. Очень высокий процент инцидентов, не привязанных ни к какой проблеме, указывает на неэффективность процесса управления проблемами и может свидетельствовать также о недостатке ресурсов.	Владелец процесса, руководство ИТ, владелец процесса SLA, бизнес-клиент, члены команды, владелец процесса SIP.
Число проблем, не решенных в течение заданного времени	Число проблем, которые остались нерешенными к намеченному дню и были эскалированы.	Оценка эффективности укладывания процесс управления проблемами в отведенные сроки	Владелец процесса, руководство ИТ, владелец процесса SLA, бизнес-клиент, члены команды, владелец процесса SIP.
Степень удовлетворенности клиентов	Степень удовлетворенности клиентов, определенная по данным процесса	Оценка степени удовлетворенности клиента на решение проблемы	Владелец процесса, руководство ИТ, владелец процесса SLA, бизнес-клиент, члены команды, владелец процесса SIP.
Пять категорий инцидентов, по которым было больше всего обращений за отчетный период	Число записей об инцидентах в каждой категории, поделенное на их общее число за период и умноженное на 100. Пять категорий, для которых это значение максимально, отображаются на секторной диаграмме.	Частота обработки идентичных запросов на решение проблем	Владелец процесса, руководство ИТ, владелец процесса SLA, бизнес-клиент, члены команды, владелец процесса SIP.
Число инцидентов, разрешаемых путем обучения пользователей	Число заявок, которые относятся к определенной категории инцидентов и для которых в качестве решения указана необходимость обучения пользователей.	К инцидентам приводят как ошибки в ИТ-инфраструктуре, так и недостаточные знания пользователей о том, как работать с приложениями. Поэтому можно предотвратить значительную часть инцидентов, просто обучая пользователей.	Владелец процесса, руководство ИТ, владелец процесса SLA, бизнес-клиент, члены команды, владелец процесса SIP.
Затраты на решение проблемы	Сколько всего стоило решение данной проблемы	Оцениваются часы работы персонала, материальные издержки и другие статьи расходов, связанные с решением проблемы.	Владелец процесса, руководство ИТ, владелец процесса SLA, бизнес-клиент, члены команды, владелец процесса SIP.

Документирование процесса

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

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

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

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

- баланс между реактивным и проективным управлением проблемами:

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

- статус и план работ по открытым проблемам.

- предложения по улучшению процесса управления проблемами.

- план обеспечения качества услуг.

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

2.9 Процесс управления отчетностью по услугам

Описание процесса

Управление отчетностью по услугам - предоставление информации по услуге в формализованном виде.

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

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

Окружение процесса

· Управление проблемами

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

· Управление изменениями

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

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

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

· Управление информационной безопасностью

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

Метрики процесса подготовки отчетности по услугам

Метрика	Описание	Задача метрики	Аудитория
Процент отчетов, не использовавшихся в течение года в области ИТ.	Количество отчетов, которыми долго не пользовались или ненужные отчеты.	Неиспользуемые документы должны периодически пересматриваться с точки зрения их существенности и возможности удаления.	Владелец процесса, руководство ИТ-отдела, владелец процесса SLA, члены команды, владелец процесса SIP.
Число несоответствий между отдельными отчетами и общим отчетом по управлению услугами по проекту ИТ.	Отчеты должны быть взаимно согласованы и отвечать политике организации. Метрика выявляет любые несоответствия.	Если централизованная подготовка всех отчетов не позволяет достичь согласованности, необходима ручная перекрестная проверка.	Владелец процесса, руководство ИТ-отдела, владелец процесса SLA, члены команды, владелец процесса SIP.
Число инцидентов, относящихся к ошибкам в отчетах.	Инциденты, которые связаны с ошибками в отчетности.	Процесс управления отчетностью должен работать так, чтобы ошибки или неверные сведения не приводили к инцидентам.	Владелец процесса, руководство ИТ-отдела, владелец процесса SLA, члены команды, владелец процесса SIP.
Число подготовленных отчетов за год, месяц, квартал.	Количество отчетов, подготовленных за определенный период.	Отчетность по периодам позволяет проводить анализ и улучшать качество выполнения проекта.	Владелец процесса, руководство ИТ-отдела, владелец процесса SLA, члены команды, владелец процесса SIP.
Число обращений в Service Desk.	Количество проблем, которые возникли у пользователей в течение работы.	Число проблем, с которыми клиент обратился в службу необходимо уменьшать, это возможно только при получении информации по всем обращениям.	Владелец процесса, руководство ИТ-отдела, владелец процесса SLA, члены команды, владелец процесса SIP.
Процент необработанных обращений в Service Desk.	Количество проблем, решенных до принятия мер сотрудниками службы поддержки.	Примерный процент ложных проблем.	Владелец процесса, руководство ИТ-отдела, владелец процесса SLA, члены команды, владелец процесса SIP.
Процент удовлетворенных скоростью реагирования клиентов на обращение в службу поддержки.	Примерная удовлетворенность клиентов службой поддержки.	Плавающая метрика, которая предоставляет информацию об удовлетворенности сервиса. Плавающая, потому что клиент может ошибиться в оценке либо специально ухудшить показатель удовлетворенности.	Владелец процесса, руководство ИТ-отдела, владелец процесса SLA, члены команды, владелец процесса SIP.
Количество реактивных отчетов.	Отчеты, которые показывают, что уже произошло.	Отображает количество проблем, которые предотвратить не удалось. Показатель со временем должен улучшаться.	Владелец процесса, руководство ИТ-отдела, владелец процесса SLA, члены команды, владелец процесса SIP.
Количество проактивных отчетов.	отчеты с прогнозами предоставления услуг.	Для заблаговременного предупреждения о важных событиях и позволяет заранее предпринять меры.	Владелец процесса, руководство ИТ-отдела, владелец процесса SLA, члены команды, владелец процесса SIP.
Количество показателей для отчетности по услугам.	Определенный список показателей для различных видов отчетов.	Благодаря общему списку показателей можно легче проводить анализ и принимать меры для улучшения качества предоставления услуг.	Владелец процесса, руководство ИТ-отдела, владелец процесса SLA, члены команды, владелец процесса SIP.

Документирование процесса

· Отчет об уровне сервиса (информация о реальном уровне предоставления услуг);

· Бухгалтерский отчет - суммарный список статей расходов и доходов по проекту;

· Отчет о результатах выполненных работ - успешные и безуспешные работы по проекту;

· Отчет о проблемах - список проблем, выявленные в течение выполнения проекта;

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

· Отчеты о сбоях - список зарегистрированных сбоев в работе;

· Клиентская отчетность - необходимая информация по проекту для заказчика (включает в себя всю информацию, необходимую клиенту: затраты, проблемы, инциденты и пр.);

· Отчеты о договорах, подписанных с подрядчиками и потребителями;

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

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

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

· Реестр неотложных вопросов (как идет работа с рисками и непредвиденными обстоятельствами. К примеру, замена ключевого сотрудника. Реестр заполняется по важности вопросов - от «незначительного» до «критического»);

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