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

На критику SLA

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

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

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

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

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

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

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

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

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

  • Андрей

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

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

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

      • Андрей

        На самом деле у подхода Agile есть давняя история. Раньше у нас это называлось сделать на коленке или на соплях.:)))

  • Маским

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

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

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


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

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

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM
;