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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Цели

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

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

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

Требования

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

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

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

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

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

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

Задачи

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

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

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

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

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

.        закрытие;

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

Принципы

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Функции

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

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

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

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

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

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

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

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

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

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

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

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

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

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