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

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

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

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

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

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

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

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

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

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

Учебные курсы и сертификация
специалистов по ИТ-менеджменту

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

  • Станислав

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

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

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

  • Георгий

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

    • Юрий Ерин

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

      В точку.

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

    • Вадим

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

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

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

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

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

        • Вадим

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

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

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

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

  • Максим

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

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

      • Максим

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

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

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

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

          • Максим

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

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

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


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

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

  • Рубрики

  •  
  • Авторы

  •  
  • Самое свежее

    • Новая модель предоставления ИТ-услуг: почему вам нужно ориентироваться на продукт
      Традиционно ИТ-организации делят все предоставляемые ими услуги на три уровня: инфраструктура (инфраструктура как услуга), платформа (платформа как услуга) и приложения
    • Как DevOps-командам следует использовать метрики DORA
      С момента выхода в 2018 году книги «Accelerate: Наука о бережливом программном обеспечении и DevOps», показатели DORA, которые она представила, стали популярным
    • Лучше делать хоть что-то, чем не делать ничего
      На конференциях по всяким Agile и DevOps мы часто слышим слово «unlearn» — забудьте то, что вы знали ранее! Измените свои представления о мире! Всё устроено
    • VI форум «Управление данными — 2021»: наведите порядок в данных!
      23 сентября 2021 года издательство «Открытые системы» в шестой раз проведет в Москве масштабный форум «Управление данными — 2021», объединяющий всех, кто определяет стратегию работы с данными, воплощает ее в жизнь и управляет предприятием на основе объективных достоверных данных. Участники форума обсудят не только инновационные стратегии и бизнес-модели работы с корпоративными данными, но и конкретные архитектурные и технологические решения.
    • Простые уловки, как ускорить процесс разработки программного обеспечения
      С некоторыми вещами люди из бизнеса вынуждены соглашаться, и одна из них заключается в том, что никто не хочет сердить свою команду разработчиков. Часто они являются краеугольным
    • Почему каждая инициатива DevOps должна начинаться с оценки возможностей
      Внедрение практики DevOps идет полным ходом. Организации сосредоточены на том, как внедрить возможности DevOps в командах и как масштабировать DevOps в масштабах предприятия. Но важным аспектом любого пути масштабной трансформации является оценка возможностей команды или организации на этом пути.
    • Что такое процесс и что такое практика в ITIL®4
      Продолжаем публиковать короткие видеоролики, посвященные актуальным вопросам управления ИТ. Сегодня поговорим о том, что такое процесс и что такое практика в ITIL4. Это не переименование процессов в практики, это два отдельных понятия. Рассказывает Игорь Фадеев, ITIL 4 Managing Professional и ITIL 4 Strategic Leader, аккредитованный тренер по ITIL4.
    • Аудит. Что может быть скучнее?!
      На прошедшей неделе участвовал в аудите (в качестве объекта аудита). Большинство людей, проходивших аудит, подозреваю, разделяет это ощущение: «Бюрократия, формальности и т.п.»
    • Как технический долг вредит вашей команде программистов — и вашей безопасности приложений
      Техническая долг может серьезно повлиять на здоровье организации - и на психическое здоровье ваших разработчиков. Более половины из 200+ членов инженерных команд, опрошенных в рамках отчета Stepsize "Состояние технического долга в 2021 году", считают, что технический долг негативно влияет на моральное состояние их команд.
    • Что люди не понимают в управлении потоком создания стоимости
      Нет ничего плохого в самом управлении потоками создания ценности (VSM), но есть много плохого в том, как его рассматривают и обсуждают блогеры, отраслевые маркетологи и другие, которые часто смешивают его с DevOps и Agile. Это не одно и то же.
  •  
  • Вход

  • DevOps
    Kanban
    ITSM
    ITIL
    PRINCE2
    Agile
    Lean
    TOGAF
    COBIT