Портал №1 по управлению цифровыми
и информационными технологиями

Критерий доступности

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

  1. Критичность бизнес-функции. Например, невозможность отправки или получения сообщений, доступа к почтовому ящику означает, что услуга «электронная почта» недоступна; недоступность календарей, адресной книги и так далее недоступностью услуги не считается. Допустимый, но грубый подход, поэтому, как правило, говорят о полной или частичной недоступности услуги, и недоступность отдельных бизнес-фукнций в зависимости от их критичности включают именно в понятие частичной недоступности услуги.
  2. Пороги производительности. Например, задержки в отправке или получении писем свыше, чем определенный период времени.
  3. Количество затронутых пользователей или точек потребления услуги. Например, услуга считается недоступной только, если инцидент затронул свыше N пользователей (офисов, площадок) или более M процентов от общего числа пользователей услуги (офисов, площадок).
  4. Группа затронутых пользователей. Например, услуга не считается недоступной, если инцидент затронул только те группы пользователей, которые используют электронную почту для внутренних коммуникаций, и считается таковой, если инцидент затронул тех, кто взаимодействует посредством электронной почты с клиентами.
  5. Время предоставления услуги. Определяется графиком предоставления услуги: например, отказ ночью или в выходные/праздничные дни, согласованное время планового обслуживания не учитываются при расчете недоступности.

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

Тип услуги

Пример

С точки зрения доступности необходимо обеспечить

ИТ-обеспечение бизнес-процесса

Выдача кредитов, ведение претензионной работы, обеспечение закрытия дня

Возможность проведения бизнес-операций в ИТ-системах

Предоставление ИТ-ресурса/доступа к ИТ-ресурсу

ИТ-системы, каналы связи, рабочая станция, виртуальные серверы

Готовность ресурсов

Деятельность сотрудников ИТ-подразделения

Сопровождение ПО, администрирование БД, доработка и конфигурирование

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

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

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

Комментариев: 9

  • Nargiza Suleymanova

    Деятельность сотрудников ИТ-подразделения

    Довольно странно видеть это в списке типов услуг. Поясните, пожалуйста.

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

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

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

      • Nargiza Suleymanova

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

         

        • Насколько я теперь понял, вопрос по вордингу, не по сути. Ведь регламентно-профилактические работы = деятельность ИТ-специалистов, верно? 🙂 Буду рад предложению по более удачному названию такого типа услуг!

          • Nargiza Suleymanova

            Абсолютно верно 🙂 Почему-то глаз режет смущает терминология. Варианты: регламентные профилактические услуги (которые уже упомянуты), поддерживающие услуги, "услуги невидимого фронта" (шучу)

            Забавно, что конкретно наши клиенты их понимают больше, чем, например, решение инцидентов. Говорят, что выезды по расписанию и отчетность по ним ясны, а вот гипотетически возможные инциденты и запросы на обслуживание — не очень (вдруг, инцидентов не будет, за что мы вам деньги платим?!). А вот по регламентным человеко-часы определены и посчитаны заранее. )

    • Андрей

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

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

  • Андрей

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

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


Добавить комментарий

Ваш адрес email не будет опубликован.

  • Рубрики

  •  
  • Авторы

  •  
  • Самое свежее

    • Внедрение ИИ для вашей службы поддержкиВнедрение ИИ для вашей службы поддержки
      Но что на самом деле означает внедрение ИИ для возможностей ITSM вашей организации, особенно для службы технической поддержки?
    • Бесплатная конференция IT-Entrance для тех, кто хочет стать айтишниками
        28 мая в Минске пройдет бесплатная 11-я международная конференция IT-Entrance. Это мероприятие для тех, кто хочет попасть в IT, для начинающих IT-специалистов уровня junior с
    • ITIL 4 Specialist: High-velocity IT. Что внутри?
      В дополнение к уже опубликованным обзорам курсов по направлению Managing Professional (MP) сертификационной линейки ITIL4, сегодня мы рассмотрим еще один модуль – ITIL 4 Specialist: High-velocity IT (HVIT).
    • Весення уборка в бэклоге продукта: порядок за четыре шага!
      Каждая команда, которая ведёт разработку ПО в соответствии с практиками Agile, имеет бэклог продукта или по крайней мере думает, что он у неё есть. Кажется, что это очень простой инструмент, но на практике я регулярно сталкиваюсь с неумением им пользоваться для планирования работы разработчиков. Давайте попробуем разобраться, для чего нужен бэклог продукта и как извлечь из него максимум пользы. 
    • Warranty и Utility в ITIL4
      У услуг, которыми мы управляем в рамках Service есть две основные характеристики: гарантия — Warranty и Utility — полезность. Эти характеристики нужны нам, чтобы определить, будет ли услуга способствовать достижению результатов, которые нужны пользователю, а как следствие — создавать для них ценность.
    • Шесть практик для лучшего взаимодействия бизнеса и ИТ
      Хотели бы вы, чтобы руководители предприятий и ИТ могли лучше работать вместе, совместно работать над проектами и в полной мере обмениваться информацией? Если вы похожи на большинство ИТ-руководителей, ответ — да. Преимущества эффективного сотрудничества между бизнесом и ИТ включают в себя специальные проекты, которые лучше соответствуют бизнес-целям, улучшенное управление изменениями и более активное участие в новых инициативах.
    • Используйте технологии для повышения эффективности рабочего процесса вашей ИТ-команды
      Эффективное рабочее место создает, так сказать, хорошо смазанную машину, повышая итоговую прибыль и, как следствие, успех вашего бизнеса. Дополнительное время на работе не всегда означает большее достижение. Важно то, что вы делаете с тем временем, которое у вас есть, а это все об эффективности рабочего процесса.
    • Хранение данных и «внутренний хомяк»
      Хранение информации, которая больше не пригодится, сопряжено со огромным количеством рисков. Иллюстрация этому — череда сливов персональных данных пользователей крупных сервисов, которую мы могли наблюдать с января по март. Кажется, что предприятиям нужны правила, когда и как избавляться от данных.
    • Action BiasAction Bias — известная ловушка, в которую мы всё равно постоянно попадаем
      Action Bias: склонность к реагированию и действию, даже если это не приведёт к положительным результатам. «Делать хоть что-то» создаёт иллюзию загрузки ресурсов полезной работой.
    • бэклог27 антипаттернов бэклога продукта
      Эта статья показывает 27 распространённых антипаттернов продуктового бэклога, включая процесс уточнения бэклога продукта, ограничивающих успех вашей Скрам-команды.
  •  
  • Вход

  • DevOps
    Kanban
    ITSM
    ITIL
    PRINCE2
    Agile
    Lean
    TOGAF
    COBIT