Как выглядит SLM в корпоративных ITSM-системах

Главный корпоративный инструмент контроля за исполнением временных нормативов — это Service Level Management, или SLM (управление уровнем услуг). В современных enterprise-платформах SLM является органической частью системы: на его основе прописываются регламенты, ведётся контроль качества оказанных услуг, определяются нарушения сроков. SLM регламентирует уровень сервиса и контролирует соответствие услуг ожиданиям потребителей.

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

ITSM SimpleOne позволяет устанавливать нормативы на любые объекты, которые можно классифицировать как задачи. То есть на все объекты типа «задача», унаследованные от головной таблицы задач, можно установить временные нормативы по исполнению. Эта функциональность сначала определяет временные рамки для обработки чего бы то ни было, а после отслеживает соблюдение этих нормативов.

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

• SLA (Service Level Agreement);
• OLA (Operational Level Agreement);
• UC (Underpinning Contract).

Что должен уметь делать SLM в ITSM-системах?

Настройка индикаторов максимально гибкая и доступна любому пользователю

В SLM-разделе любой качественной ITSM-системы есть функции настроек индикаторов, это стандарт. Тем не менее мы гордимся тем, насколько простыми в использовании у нас получились эти настройки. На платформе SimpleOne мы довели их до такого уровня простоты, что настройка весьма сложной логики расчёта индикаторов качества обходится без скриптов: все (даже самые изощрённые) настройки, кастомизация, введение дополнительных параметров производятся визуально инструментами No Code.

Индикаторы (правила расчёта времени) опираются на календари

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

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

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

Зонтичный SLA: подчинённые соглашения

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

Ретроспективный старт счётчиков времени

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

Процентный пересчёт счётчиков времени при ретроспективном старте

Этот инструмент появился в арсенале нашего SLM благодаря обратной связи от заказчиков. Они обратили наше внимание на проблему, которая может возникнуть без доработки ретроспективного выставления счётчиков.

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

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