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

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

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

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

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

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

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

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

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

Share on FacebookTweet about this on TwitterShare on Google+Share on LinkedInEmail this to someone

ITIL ITIL Intermediate: Service Offerings and Agreements

Учебный курс: проектирование и предоставление ИТ-услуг, SLA и SLM, экономика и финансы ИТ, управление поставщиками и подрядчиками — в ITIL и на практике.
 

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

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

  1. Станислав

    Безупречная тема

    И ее надо двигать

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

    0
    0
  2. Георгий

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

    0
    0
    1. Вадим

      Не Дмитрий, но предложу свой вариант.

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

      Вот эта вот совокупность и составляет «подчинение».

      0
      0
      1. Константин Нарыжный

        Вадим, я примерно так же себе это представляю, но Дмитрий пишет о том, что ИТ-шники наоборот считают, что бизнес «не дорос» до них. Более того, из личного опыта: многие из ИТ действительно понимают бизнес-модель (особенно те, кто имеет дело с бизнес-приложениями) и делают верные прогнозы по развитию.

        А про подчинение у меня возникло сомнение в трактовке слова «бизнес»: «хозяин» или «ведущий исполнитель»? Если «хозяин», то CIO равноправен с другими «ведущими исполнителями», а не подчиняется им, соответственно — как с равными может соглашаться с ними об уровне услуг. Так?

        0
        0
        1. Вадим

          отвечу кратко:

          — про «бизнес не дорос до ИТ» = обычный ИТишный снобизм. однако термин «уровень созрелости» никто не отменял (изменено намеренно, это именно созрелость, а не зрелость)

          — я согласен в том, что есть «хорошие» ИТишники, которые «действительно понимают бизнес-модель», я таких знаю, я тоже такой :о))) (скромн.)

          — по остальному нет комментариев, точнее их слишком много, но сводятся к одному: встать на одну ступеньку (быть равноправным) нужно еще суметь.

          0
          0
  3. Максим

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

    0
    0
      1. Максим

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

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

        0
        0
        1. Дмитрий Исайченко Автор

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

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

          0
          0
          1. Максим

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

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

            0
            0
            1. Дмитрий Исайченко Автор

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

              0
              0

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

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

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

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

НОЯ
27
Учебный курс:
Основы ITIL (очно)
ДЕК
4