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

Зачем бизнесу SLA?

В последнее время благодаря нашим клиентам мы довольно много времени уделяем обсуждению сервисного подхода в целом (как способа управления ИТ) и SLA в частности (как одному из артефактов). И я не могу не поднять эту тему, хоть и долго пытался сдерживать себя. А тема такова: бизнес-подразделениям / руководителям SLA нужны только в очень ограниченном наборе случаев (ВАЖНО: я не говорю здесь о SLA между участниками коммерческих отношений, только про SLA между ИТ-подразделением и бизнес-подразделениями, зависящими от ИТ).

Почему? Основная причина проста – соглашение предполагает равенство участников (во всяком случае в тех аспектах, которые касаются интересов сторон соглашения). Помните, как Пифагор определил дружбу? «Дружба это равенство». Если же одна сторона является заведомо подчинённой (ИТ-подразделение), то доминирующей стороне SLA не нужен – он ничего не гарантирует, однако зачем-то вносит ограничения. Именно такие отношения наиболее распространены вокруг нас. Тому есть несколько причин: традиции декларативного управления, исключительно поддерживающая роль ИТ-подразделения (в противовес лозунгам о стратегическом партнёрстве), неготовность ИТ-подразделения предоставить гарантии выполнения обязательств, существенная разница между потребностями бизнес-подразделений и предлагаемыми условиями SLA…

Случаи, когда SLA действительно могут быть востребованы бизнесом, крайне редки. Например:

  • ИТ-подразделение в существенной степени независимо от потребителей. Например, в международной компании европейский ЦОД может предоставлять услуги подразделениям в разных странах (и необязательно на коммерческой основе), которые на сотрудников и руководство ЦОДа имеют крайне слабое организационное влияние, а SLA такое влияние может предоставить / усилить.
  • Бизнес-руководитель высокого уровня, курирующий ИТ, зависит в оценке своей работы (в своих бонусах, например) от качества работы ИТ-подразделения. В этом случае он может быть заинтересован в SLA как в защите своих интересов.

В большинстве других случаев ИТ-шники сколько угодно могут сетовать на то, что «бизнес до них не дорос», «незрел» и так далее. Суть не в зрелости, а в том, что бизнес-руководителям это просто не нужно. Это не в их интересах.

Мне могут возразить и привести массу контрпримеров. Но прежде чем приступить, проверьте себя:

  • Содержатся ли в Вашем примере SLA такие компоненты как L (Level – набор измеримых характеристик услуги) и A (Agreement – осознанное соглашение двух сторон)?
  • SLA, который Вы выдвигаете в качестве примера нужен именно бизнесу?
  • Если это так, используется ли он бизнесом после того, как однажды был подписан: выполняется ли его пересмотр, контролируется ли его соблюдение и так далее?

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

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

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

  • Станислав

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

  • Георгий

    “− Именно, именно, − закричал он, и левый зеленый глаз его, обращенный к Берлиозу, засверкал, − ему там самое место! Ведь говорил я ему тогда за завтраком: “Вы, профессор, воля ваша, что-то нескладное придумали! Оно, может, и умно, но больно непонятно. Над вами потешаться будут”.

    • Юрий Ерин

      “Вместе с тем, уж простите за крамольную мысль, SLA вовсе не является обязательным инструментом и неотъемлемой частью сервисного подхода…”

      В точку.

  • Дмитрий, а разовьёте мысль про подчинение ИТ бизнесу, пожалуйста?

    • Вадим

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

      • Вадим, я примерно так же себе это представляю, но Дмитрий пишет о том, что ИТ-шники наоборот считают, что бизнес “не дорос” до них. Более того, из личного опыта: многие из ИТ действительно понимают бизнес-модель (особенно те, кто имеет дело с бизнес-приложениями) и делают верные прогнозы по развитию.
        А про подчинение у меня возникло сомнение в трактовке слова “бизнес”: “хозяин” или “ведущий исполнитель”? Если “хозяин”, то CIO равноправен с другими “ведущими исполнителями”, а не подчиняется им, соответственно – как с равными может соглашаться с ними об уровне услуг. Так?

        • Вадим

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

  • Максим

    Возможно дело в том, что для ИТ SLA это не Agreement, а Declaration. Кстати, при всем ущербности такого подхода он имеет и одно достоинство – у партнера появляется понимание границ возможного и с течением времени бизнес начинает учитывать эти границы при планировании своей деятельности.

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

      • Максим

        “Видишь суслика? — Нет. — И я не вижу. А он есть!” Фильм “ДМБ”.

        От того, что автор поручения не знает о существование границ, границы не исчезли. А переход через них в реальной жизни означает перерасход денежных средств, повышенная нагрузка на персонал, снижение качества, сдвиг сроков и т.д. А SLA (вернее SLD) позволяет обозначить эти границы.

        • Я думаю дело не в суслике … или по крайней мере не только в нем 🙂

          Наверно главный вопрос, который определяет отношение к теме заключается в следующем: “Как Вы думаете, зачем люди делают бизнес – для того, чтобы точно планировать, учитывая все имеющиеся ограничения, или для того, чтобы зарабатывать деньги вопреки ограничениям?”. Только один вопрос, дальше все будет просто.

          • Максим

            Дискуссия начинает приобретать философский характер;-)

            Поскольку мы не в Кнессете, то позволю себе ответить вопросом: “Таки зарабатывать деньги вопреки любым ограничениям?” Может все-таки стоит принимать во внимание ограничения, налагаемые федеральным законодательством и законами физики, физическими возможностями людей и их психологией? А следствием перечисленного становятся ограничения на возможности создать ИТ-систему с доступностью 101% или выполнения заявки вчера. Увы, это придется учитывать и лучше это сделать заранее.

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


Добавить комментарий для ВадимОтменить ответ

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

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM