ITSM, SLM и особенности учёта временных нормативов в распределённой компании

Компания, которая предоставляет услуги, несёт ответственность за их качество. Чтобы формализовать критерии качества и обслуживания между поставщиком услуги и потребителем, заключается Service Level Agreement (SLA) — документ, сформированный в результате процесса Service Level Management (SLM). И в первую очередь стороны договариваются об учёте временных нормативов, а считать их помогают ITSM-системы, такие как SimpleOne.

SLM — это не только время

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

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

Временные нормативы на практике

Допустим, у компании есть веб-приложение, которое отвечает за выполнение критичного для бизнеса процесса. Это может быть CRM-система, торговая площадка, ERP-система и любая другая, отвечающая за бизнес-сервис, отказ в работе которого сопровождается финансовыми и репутационными издержками. Например, когда «падает» сайт интернет-магазина, останавливается торговля, компания не получает прибыли, а клиенты уходят к конкурентам.

Поддержка работоспособности такого веб-приложения — это услуга, потребителем которой выступает бизнес, а поставщиком — ИТ-подразделение. Задача последнего — предоставлять услугу эффективно и без сбоев, а в случае их возникновения оперативно возвращать систему в рабочее состояние. Так как сложно гарантировать безотказную работу всех сервисов, стороны договариваются о временном нормативе функционирования услуги, например об уровне доступности 99,6% за отчётный период, и фиксируют его в SLA. Это значит, что у поставщика есть время на устранение аварий в размере 0,4% от времени предоставления услуги за отчётный период. Например, при отчётном периоде в месяц для ноября будет справедлив следующий расчёт. 30 дней — это 720 часов работы сервиса, согласно подписанному SLA он может быть недоступен 0,4% времени работы — это около 172 минут. Столько времени в месяц есть у технической поддержки для восстановления работы услуги без нарушения SLA.

Как только первый инцидент в отчётном периоде зарегистрирован системой мониторинга, создаётся запись в ITSM-системе и начинает «тикать счётчик» настроенного индикатора. У службы технической поддержки есть 172 минуты, чтобы устранить аварию, в противном случае выставляются штрафные санкции, которые также описаны в SLA. Счётчиков может быть несколько: один считает общее время простоя, другой — время реакции на инцидент и оповещение пользователей, третий — количество инцидентов за отчётный период и так далее — любые метрики, о которых договорились стороны.

Например, в течение месяца произошло пять «падений» сайта, каждый раз техническая поддержка справлялась с аварией за 30 минут. Общее время, затраченное на восстановление услуги, — 150 минут, что укладывается в параметры SLA, но в нём есть пункт, который допускает не более четырёх отказов в месяц. Следовательно, SLA нарушен, что влечёт за собой штраф, неустойку или расторжение договора.

Все эти нюансы учёта должна поддерживать функциональность SLM в корпоративной ITSM-системе.

Среди задач SLM в этом контексте можно выделить следующие.

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

Особенности учёта временных нормативов

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

Календарь рабочего времени

Для компаний, которые не работают в режиме 24/7, бизнес-критичное время напрямую зависит от рабочего календаря. Следовательно, время простоя задаётся и должно рассчитываться с учётом календаря рабочего времени.

Разница часовых поясов

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

Работа офиса в Новосибирске ещё кипит, а служба технической поддержки в Калининграде даже не вышла на работу. В случае аварии без чётко прописанных регламентов начало её устранения может затянуться. Вопрос решается передачей офиса на обслуживание местному подразделению ИТ или добавлением в SLA расходов по переработке в нерабочее время. Все договорённости должны быть сделаны в рамках SLM до начала предоставления услуги и согласованы обеими сторонами.

Иерархия соглашений

У поставщика услуги может быть несколько уровней поддержки. Так, первый принимает, классифицирует и маршрутизирует обращение, второй решает проблему на уровне программного обеспечения, третий отвечает за оборудование, а четвёртый — за внешний сервис (службу поддержки вендора и т. п.). В SLA описаны отношения между конечным потребителем и поставщиком, у которого могут быть и другие внутренние взаимодействия.

Чтобы гарантировать потребителю заданный уровень сервиса, поставщик должен зафиксировать в дополнительных соглашениях все внутренние договорённости. Для этого существуют операционные соглашения об уровне поддержки — Operational Level Agreement (OLA). В них прописаны внутренние ответственности участников предоставления услуги наружу.

Для учёта соглашений с внешними поставщиками используются внешние контракты, так называемые Underpinning Contract (UC). Так, если дата-центр, в котором размещено оборудование поставщика услуги, гарантирует доступность 99,5%, то сам поставщик не может гарантировать потребителю доступность свыше этого значения, например 99,7%.

SLM в ESM-системе SimpleOne

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

Платформа SimpleOne способна учитывать любые особенности взаимодействия между поставщиком и потребителем услуг, характерные для корпоративного сегмента. SLM в ESM-системе SimpleOne — гибкий, надёжный и удобный инструмент для крупных компаний.