На критику SLA

regardlessВ последнее время мне как-то часто стала попадаться на глаза критика SLA. Замечания сильно перекликаются с теми, которые я отмечал для себя несколько лет назад, работая в команде над составлением SLA в одной из компаний. На первых встречах с заказчиками мы тоже часто слышали высказывания в духе: "Зачем нам SLA? Мы и без них прекрасно обходимся", "Вы предлагаете нам новый порядок взаимодействия? А зачем?", "Вы же хотите подстраховаться?".

Вот и сейчас звучат голоса авторов, кто предлагает новые формы, а кто-то вообще считает соглашения об уровне обслуживания отжившими своё. Но, как поётся в одной песне: "А не спеши ты нас хоронить, а у нас еще здесь дела" ©.

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

Как быть? Стоит ли отказаться от SLA? Не думаю. Ведь SLA благодаря своему назначению позволяет предметно зафиксировать начальную точку заботы о качестве предоставляемых заказчикам услуг. Описание услуги, параметры поддержки, доступности, производительности, безопасности и других важных для заказчика характеристик, а также их измерений -  всего того, с чего начнётся первый шаг на пути постоянного совершенствования. Использовать инструмент можно по-разному. Бизнесу нужно развитие. И если не следовать потребностям бизнеса — не подтягивать вслед за ним уровень предоставления — SLA, действительно, окажется не у дел, превратившись из инструмента развития в средство сохранения статус-кво, а вскоре будет отброшено за ненадобностью.

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

Внутренний поставщик услуг зачастую находится в других условиях — не на равных с бизнесом, а в подчинённом положении. Заинтересовать бизнес соглашениями, состоящими из ограничений, из такого положения невозможно. Такие SLA точно будут "неживыми". Однако, ключом к закреплению и развитию практики SLA в этих условиях может стать следование путём совершенствования услуг, обеспечивающих бизнес-процессы. Кому, как не внутренним ИТ, лучше всего известны бизнес-процессы своих заказчиков? Именно акцент на развитии услуг для повышения эффективности поддерживаемых бизнес-процессов, как я представляю, и позволит со временем сменить подчинённую позицию на равноправную, партнёрскую (commodity -> partner). И здесь-то и должны сыграть свою положительную роль SLA с зафиксированными планами по развитию услуг.

По моему мнению, SLA — "живой документ", не стоит предавать его забвению. А как вы считаете?

ITIL Expert Уверенная дорога до ITIL Expert
 

Экономия на обучении до 30% для тех, кто хочет быстро добраться до высшей ступени в ITIL
 

Узнайте больше!

Комментарии и мнения

  1. Андрей

    Все эти разговоры в русле современной тенденции в сторону шустрости(Agile). Там тоже призывают не тратить время на всякие формальности, поскольку все нужно быстро. Под формальностями, в частности, некоторые особо шустрые понимают даже ТЗ — документ, защищавший заказчика от того, что ему сделают некую чушь вместо того, что он просил, и исполнителя, когда заказчик будет отказываться принимать работу под надуманными предлогами. Я продолжаю навязывать индустриальный подход. Посмотрите как в промышленности. Там есть ТУ, ГОСТ, сертификаты соответствия и т.д. И, заметьте, никто не говорит, что нам быстро нужны новые продукты и давайте отменим всё это. Так вот SLA — это такой же ГОСТ и т.д., определяющий параметры качества ИТ услуги как продукта. И не важно, внутренний это ИТ или внешний. На предприятиях есть внутренние службы — ремонтные, службы энергетика и т.д., и они все руководствуются ГОСТ(ну хорошо, должны руководствоватся:) ). По поводу причин нежелания бизнеса оформлять SLA -одна из причин состоит в информационной безграмотности, когда человек не может дать четкий ответ на вопрос — какая информация тебе нужна для выполнения твоих бизнес процессов. Какая, в том числе, и с точки зрения качества.

    1. Денис Денисов Автор

      Подумалось, а как Agile мог бы выглядеть (вопрос применимости давайте исключим) в таких областях, как: то же строительство, водо- и энергоснабжение?

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

  2. Маским

    Agile модная тенденция, как в свое время экстремальное программирование.

    Им еще не накушались вдоволь))

    Альтернативы SLA не вижу, также как не вижу альтернативы юридическим договорам между сторонами.

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

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Ближайшие мероприятия

Зарегистрируйтесь, чтобы получить больше полезных знаний:

ДЕК
17
Учебный курс:
Основы DevOps 
ДЕК
20
ДЕК
20