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

Default SLA

Опубликовано 30 августа 2012
Рубрики: SLA, SLM, BRM, Обо всём на свете, Практика и опыт
Комментарии

При проектировании процесса SLM не раз сталкивался с вопросом со стороны заказчика: "как мы заставим бизнес подписывать с нами SLA? Это же за ними бегать надо, договариваться, убеждать …". В итоге в рамках одного из проектов родилось решение, которое уже проверено практикой и, как минимум, имеет право на жизнь.

Хочу поделиться и узнать Ваше мнение.  

Что если на этапе старта процесса формируется SLA "AS IS", фиксирующий текущий уровень предоставления ИТ-сервисов на основании текущей практики и собственного видения ИТ на то, как надо предоставлять ИТ-сервисы. SLA вводится в действие без согласования с каждым Заказчиком, просто как неотъемлемая часть запускаемого процесса.

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

Таким образом с одной стороны упрощается первичный сбор требований, с другой обеспечивается возможность для бизнеса высказать свое мнение и скорректировать положения SLA.

Ну вот, поделился. Что скажете?

ИНТЕНСИВ С ТРЕНЕРОМ
VAP: Управление уровнем услуг и каталогом услуг
Разработка каталога, SLA, метрик качества, расчёт доступности

Также по теме:

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

  • Юрий Ерин

    Разумный подход. В “хорошей” практике, как правило, именно так и происходит.

  • Дмитрий Исайченко

    “SLA вводится в действие без согласования с каждым Заказчиком”

    А как (вводится в действие)? Что является основанием? Почему последующие апелляции к этому SLA должны быть услышаны и приняты потребителем?

    • Евгений Шилов

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

      При этом достаточно высокий уровень утверждения документа является основанием для того чтобы на него можно было ссылаться.

      • Андрей В.

        “..если есть руководитель со стороны бизнеса курирующий ИТ, то может быть достаточно согласования с ним для того чтобы документы вступил в силу”

        так это и есть штатный заказчик SLA и абсолютно штатная процедура согласования и утверждения SLA.

        • Евгений Шилов

          Андрей, на начальном этапе так и есть. Но находясь высоко, он не сможет детализировать требования или спрогнозировать изменение характера потребления, не тот уровень.

          • Андрей В.

            Евгений,
            если заказчик какой-нибудь очень занятой топ менеджер(“VIP-пользователь”:), то он может выделить т.е. “представителей заказчика”, которые поближе к полевым условиям. SLM работает (пересматривает SLA)далее с представителями заказчика.

        • Дмитрий Исайченко

          “так это и есть штатный заказчик SLA”

          Если я правильно понимаю мысль Евгения, это не заказчик SLA. Это лицо, курирующее ИТ-подразделение. А значит оценка его труда в том числе зависит от того, как оценивают результат деятельности ДИТ. А значит он заинтересован в заключении SLA, чтобы сделать такую оценку менее субъективной. То есть это скорее сторона поставщика ИТ-услуг, пусть и вне ИТ-подразделения.
          Заказчиками могут, например, выступать руководители (возможно, такого же ранга) других подразделений предприятия. Кто-то из них захочет формализации, потому что увидит в этом пользу и для себя, кто-то – нет. Тех, кто “нет” мы не будем убеждать и уговаривать, а _сообщим_ им некие стандартные условия, которые действуют, если не переопределены в SLA. Вот тогда, если вас устраивают эти стандартные условия, нет и вопросов. Не устраивают – давайте договариваться о других, заключая SLA.
          Такой подход позволяет сократить количество контрагентов и сконцентрировать усилия на тех подразделениях, кто видит в этом смысл, вместо того, чтобы пытаться договориться со всеми, включая абсолютно незаинтересованные подразделения.

  • Вадим

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

    • Евгений Шилов

      Вадим, само собой, куда же в SLM без встреч 🙂

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

      • Вадим

        я с этим согласен – именно это и имел в виду под “второй частью”, видимо, в ночи показалось это очевидным.

  • Кирилл Федулов

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

    • Евгений Шилов

      Кирилл, я разделяю вашу точку зрения насчет наивности ;-)))

      А почему вы “в первые полгода стараетесь заставить”? Разве деятельность по взаимодействию не должна стать регулярной на протяжении всей жизни процесса? При этом инициация встреч со стороны ИТ на регулярной основе конечно является обязательной, причем цели встреч могут и должны выходить за рамки “инициации этих требований” (см. комментарий http://www.realitsm.ru/2012/08/default-sla/#comment-10421).
      Но в предлагаемом подходе важно другое и пост собственно про это, что такие встречи упрощаются, если сторонам есть от чего отталкиваться, Default SLA позволяет начать работать, а затем уточнять требования на основании опыта работы по нему. Прийти к бизнесу и “инициировать требования” с нуля в большинстве случаев – игра в угадайку. Как говорится “Такие цифры на полу не валяются, их с потолка надо брать”. Поэтому первую итерацию ИТ может сделать самостоятельно, а затем уточнять по ходу встреч с бизнесом.

      • Кирилл Федулов

        Евгений, чтобы избежать споров, сперва еще раз подчеркну, что с сутью вашего поста и подхода я согласен. Мы так делаем давно и часто. Отмечу лишь, что “с потолка” стараемся цифры не брать. Если есть хоть какая-то старая система/статистика по обработке заявок, мы методами стат.анализа выявляем тренды. Это позволяет более корректно заложить хоть какие-то параметры Default Sla.

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

  • Grigory Kornilov

    Определить и согласовать “общую картину мира”, текущее состояние (as is) важно\полезно.
    И так у бизнеса есть участие некоего подраделения (IT) в общем бизнес-процессе с текущими характеристиками качества.

    Вы по сути предлагаете оформить отношения в виде “сервис\SLA”? , бизнес спросит “Что мне дает подпись и что она у меня заберет? Почему вы инициируете это изменения взаимоотношений, какова ваша цель\бенефиты от этого?”, какие есть предложения по вариантам ответов на подобные вопросы?

  • Pavel Solopov

    Я бы сказал несколько по другому, для начала ИТ надо “взять на себя обязательства”, не пытаться “рахделить обязательства” с, так называемым, бизнесом. А именно взять в одностороннем порядке.
    А дальше глядишь и какой-то диалог завяжется.

    • Георгий

      Павел, описанный Евгением вариант именно так и предполагает. Одностороннее принятие ИТ-отделом обязательств по SLA с тем, чтобы впоследствии был возможен диалог

      • Pavel Solopov

        А я и не против. Я просто переформулировал ту же идею, но другими словами. Как мне кажется, более лаконично.
        Хотя возможно, мне это только кажется.

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

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

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM
Авторы и редакторы портала — консультанты и тренеры компании Cleverics.
Использование материалов данного сайта допускается исключительно с разрешения правообладателя.
Использование данного сайта означает согласие с обязательством соблюдать нашу Политику конфиденциальности и Согласие на обработку персональных данных.