Позвольте задать вам несколько вопросов:

• Существуют ли в вашей организации соглашения об уровне услуг (SLA) между ИТ-отделом и старшими менеджерами компании, не являющимися ИТ-специалистами?
• Привели ли ваши SLA к значительному положительному влиянию на организацию?
• Улучшили ли ваши SLA восприятие и репутацию вашей ИТ-организации?
• Есть ли у ваших старших бизнес-менеджеров ясность в отношении того, как инвестиции в технологии принесли бизнес-результаты? Признают ли эти руководители реальную ценность для бизнеса от этих инвестиций?
• Могли бы вы охарактеризовать отношения между ИТ-отделом и этими старшими менеджерами как здоровые, деловые и взаимовыгодные?

Многие ИТ-организации ответили бы на первый вопрос “да”, но у них нет SLA, которые были бы задокументированы, согласованы или подписаны между ИТ-организацией и старшими менеджерами, не являющимися ИТ-специалистами. Но предположим, что у вас есть задокументированные и подписанные SLA – как вы ответили на остальные вопросы?

Если ни на один вопрос вы не смогли ответить “да”, тогда следовало бы спросить – действительно ли у вас есть SLA?

Цель SLA – установить общее взаимопонимание того, как организация реализует бизнес-результаты и бизнес-ценности от своих инвестиций в технологии и их использования. Согласно ITIL®4, соглашение об уровне услуг – это “документированное соглашение между поставщиком услуг и заказчиком, в котором определены как требования к услугам, так и ожидаемый уровень обслуживания”.

Это определение дает нам несколько моментов, которые необходимо понять, чтобы определение и использование SLA было эффективным.

Во-первых, SLA касается услуги – “средства создания совместной ценности путем содействия достижению результатов, которых хотят добиться заказчики”. Это говорит нам о нескольких вещах, которые должны обсуждаться в SLA: что ценно для заказчика и каких конечных результатов он хочет достичь.

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

Множество “SLA” не является соглашением об уровне услуг

Это подводит нас к проблеме с SLA. Как показывает опыт экспертов, многие соглашения об уровне услуг даже не документированы; еще реже в них обсуждаются услуги. Скорее, то, что многие ИТ-организации называют “SLA”, является настройками конфигурации в их инструментах ITSM. Еще больше усугубляет ситуацию то, что эти параметры конфигурации, как правило, не имеют никакого отношения к услугам, а скорее связаны с операционной деятельностью ИТ-организации. Другими словами, “SLA” – это не про организацию, а про ИТ.

Но это не единственная проблема. Многие ИТ-организации готовят отчеты о выполнении этого так называемого “SLA”, включая такие показатели, как ASA (среднее время ответа, average speed to answer), MTTR (среднее время решения, mean time to resolve), FCR (количество решений при первом звонке, first call resolution), время отклика и другие операционные показатели. Эти показатели не имеют практически никакого значения для коллег, работающих вне ИТ.

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

Значит, сначала нам нужно определить наши услуги, верно?

В идеале – да. Определение услуг с точки зрения ценности для бизнеса и бизнес-результатов должно быть определено до разработки SLA.

Но многие организации не решаются – или полностью игнорируют необходимость – определить и документировать услуги. Некоторым ИТ-организациям сложно определить услуги, потому что они не знают бизнеса. ИТ-руководители часто поднимаются на свой уровень благодаря своим техническим знаниям, а не обязательно знаниям бизнеса. Вместо того, чтобы привлекать других бизнес-лидеров, такие руководители рассматривают определение услуг как технологический вопрос и проводят “картирование услуг”. Составление карты услуг – это просто обнаружение сети, начиная с некоторой начальной точки, ориентированной на конечного пользователя, и заканчивая некоторой конечной точкой.

Извините, это не услуга – это карта сети.

Некоторые ИТ-организации перечисляют все приложения, разработанные и внедренные ИТ-отделом, и называют этот список своими “услугами”. Поначалу это может быть нормально, пока приложение не выйдет из эксплуатации или не будет заменено. И что тогда? Исчезла ли потребность бизнеса? Скорее всего, нет. Приложения, как правило, являются компонентом услуги, но не услугой.

Некоторые ИТ-организации используют то, что многие производители программного обеспечения называют “каталогом услуг”, который представляет собой просто каталог запросов на обслуживание, содержащий списки сервисных операций и запросов на товары и доступ, которые конечные пользователи могут запросить у ИТ-отдела. Важная вещь? Да, но, опять же, это не услуга – это запросы на обслуживание.

Можно понять эту нерешительность или отказ от определения услуг. Выявление и определение услуг, а также создание (настоящего) каталога услуг – это большой объем работы, который редко приносит немедленную финансовую отдачу в первый год. Но определение услуг позволяет установить общее понимание того, что ценит организация, и ожидаемых результатов от использования технологии – темы, которые должны обсуждаться в рамках SLA.

Починить сломанные SLA

Ваши соглашения об уровне услуг “сломаны”? Если ваши текущие SLA не привели к значительным положительным последствиям для организации, не улучшили репутацию ИТ-команды, не внесли ясность в ценность для бизнеса и результаты инвестиций в технологии, не помогли сформировать прочные рабочие отношения между ИТ-отделом и старшими менеджерами, остановитесь. У вас действительно нет SLA. По крайней мере, перестаньте называть эти внутренние ИТ-мероприятия и меры “SLA”, потому что это не так. Эти внутренние ИТ-мероприятия и меры – это показатели эффективности ИТ, которые мало что значат для тех, кто не работает в ИТ-отделе вашей организации.

Действительно ли вам нужны SLA? Кто в вашей организации просит SLA? Если ваша ИТ-организация (включая высшее ИТ-руководство) не возьмет на себя обязательства по документированию, согласованию, измерению, отчетности и регулярному пересмотру SLA с высшим бизнес-руководством, то не тратьте время на разработку SLA. SLA, которые не приводят к положительному влиянию на организацию и деловые отношения, – это пустая трата времени.

Если вы подошли к этому моменту, но не определили настоящий каталог услуг, вот некоторые вещи, которые вы можете сделать, чтобы исправить свои неработающие SLA:

Разместите текущие показатели там, где они должны быть. Такие показатели, как средняя скорость ответа (ASA) и время обработки (HT), относятся к сервису деск. Такие показатели, как среднее время решения (MTTR), относятся к управлению инцидентами. Эти показатели не входят в SLA. Они относятся к ИТ. Эти показатели отражают внутреннюю производительность ИТ-команды, а не то, как услуга соответствует ожиданиям бизнеса в отношении ценности и результатов.

Найдите показатели, которые важны для вашего бизнеса. Заявления о миссии, видении и целях (mission, vision, goals, MVG) организации – отличный источник информации о том, что важно для бизнеса, даже если вы не определили услуги с точки зрения ценности и результатов для бизнеса. Определите, каким образом ИТ вносит вклад в достижение организацией своих MVG или позволяет ей их достичь, измерьте этот вклад и включите эти показатели в соглашения об уровне обслуживания.

Найдите показатели, которые важны для вашего бизнеса. Многие организации регулярно проводят анализ влияния на бизнес (BIA). В ходе BIA определяются жизненно важные бизнес-функции организации (vital business function, VBF) и количественно оценивается влияние потери услуг. VBF – это функция, без которой организация не сможет существовать. Например, VBF банка включают прием депозитов и выдачу кредитов. Как ИТ позволяют банку успешно выполнять эти VBF?

Ознакомьтесь с последним BIA организации. Определите показатели, которые указывают на бизнес-результаты выполнения этих VBF, и то, как ИТ вносит вклад в эти результаты, и включите эти показатели в SLA.

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

С оригиналом статьи можно ознакомиться по ссылке, а с вопросами выстраивания каталога услуг и управлением уровнем ИТ-услуг – на нашем курсе VAP: Управление уровнем ИТ-услуг и каталогом ИТ-услуг.

ИНТЕНСИВ С ТРЕНЕРОМ

VAP: Управление уровнем услуг и каталогом услуг

Разработка каталога, SLA, метрик качества, расчёт доступности