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

С чего начинается … SLM

Опубликовано 23 декабря 2012
Рубрики: ITSM, SLA, SLM, BRM, Всё это - ЛЮДИ
Комментарии

Как и в песне про Родину, можно придумать много начал для SLM. Нужна какая-то форма каталога услуг? Скорее всего, нужна. Нужна какая-то фиксация обязательств? Скорее всего, нужна. Контроль исполнения обязательств? Да. И так далее.

Но, как мне кажется, SLM, как деятельность по управлению, начинается с того, что с двух сторон (заказчик и поставщик) появляются люди, получившие и осознавшие свою ответственность за данную услугу. Большинство реальных результатов и достижений SLM ложится на плечи именно этих людей. Могу с уверенностью утверждать это не только по итогам прочтения книг, но главное – по итогам выполнения проектов.

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

Быстрых побед здесь ожидать не приходится. Но если этого не будет, ценность усилий по организации и исполнению SLM вряд ли оправдает Ваши ожидания. Думаю, наличие и реальные действия ответственных за услугу с обеих сторон, является одной из основных «лакмусовых бумажек» SLM, как дееспособного процесса.

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

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

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

  • Константин Нарыжный

    Из личного опыта дополню: силой воли или административного воздействия необходимо сделать эти очные встречи ритмичными, с одинаковыми интервалами, повесткой, расписанием, продолжительностью. Перефразируя классика: “Оценка услуг как привычка” (http://www.cleverics.ru/ru/subject-field/presentations/itsm-as-a-habit).

  • Grigory Kornilov

    Вовлеченность, заинтересованность и ответственность … подскажите, исходя из ваших практик, какая форма связи заплаты\премий для роли Service Manager показателей SLM лучше всего подходит, работает?

  • Станислав Уштей

    Интересно, а где же я живу 🙂

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

      Служба заказчика?

      • Станислав Уштей

        Сомневаюсь – совсем непохоже. Ну вот же ни одно из действующих действий – не соответствует описанному выше. Может я сплю и мне все это сниться, а где то есть настоящий Мир бушующий и прекрасный, где всегда есть несколько сторон и они, эти стороны, общаются между собой с взаимопониманием к взаимной выгоде и процветанию своей Страны, Родины, Отчизны, Народу…..

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

          1. Я описываю реальную ситуацию.
          2. Она не является исключительным достижением единственного проекта.
          3. Это не значит что она легко воспроизводима. Организация такой среды взаимодействия – нелегкий труд. Как я и говорил, никаких блиц-кригов.
          4. Это совсем не идеальный мир, поэтому такая ирония вряд ли точна. Но в нем есть проблески света в конце тоннеля 🙂 Тем и живем.

  • Михаил

    Дмитрий,

    Давай возьмем холдинг какой – тот же Рольф, например, в котором я работал.
    А как сервис – набившую оскомину “Электронную почту” (чур не придираться к названию сервиса).
    Сервис этот нужен всем, да вот конечным ответственным от бизнеса может являться только CEO или, в лучшем случае, CFO/COO всей группы компаний. А им, конечно, не до итерационных бесед на тему.

    Как выходить из ситуации?

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

      Это очень правильный вопрос. Я знаю на него два ответа:
      1. Заказчиком по отношению к таким базовым услугам выступает коллегиальный орган (например, служба заказчика, технологический комитет, коммерческая служба и так далее). Соответственно, SLA становится ближе к корпоративному стандарту, чем к индивидуальному соглашению.
      2. Заказчиков у такой услуги становится несколько (либо мы рассматриваем электронную почту для разных заказчиков как независимые тиражируемые услуги, либо “переносим” роль заказчика с услуги на SLA).
      Но будет ли таких услуг много, существенно зависит от того, каким образом мы формируем каталог услуг. Например, в моем текущем проекте из 73 услуг в каталоге таких (базовых) услуг только 7 (остальное – специализированные услуги с одним заказчиком), поскольку изначально при формировании каталога максимально преследовался принцип единого заказчика.

      • Михаил

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

        Со вторым вариантом другие проблемы – для меня это в первую очередь уровни сервиса и ресурсно-сервисная модель.
        Допустим, 9 из 10 готовы работать по схеме 8х5, а вот десятый хочет 12х7.
        При этом мы понимаем, что под этого десятого нам надо расширять штатку (прошу заметить, что мы, как часть Central services, не самостоятельное юр. лицо на хозрасчете и наша независимость достаточно ограничена), и наш CFO просто говорит – нет, брать никого не будем.
        Итого по второму пункту: с уровнями сервиса поиграли, и будет. Убеждаем всех, что 8х5 это отлично, бизнес-заказчики (или назначенные ими) понимают, что все эти “ЭсЭлЭмы” это профанация и все глохнет.

        Как лечить будем?

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

          Миша, мне кажется, ты смешиваешь два вопроса. Первый – несколько заказчиков, возможности по индивидуализации ограничены. Зачем тогда несколько заказчиков, если всем достанется усредненный вариант? Второй – один из заказчиков (даже не важно, является ли он единственным заказчиком услуги или одним из многих) хочет слишком многого, не распоряжаясь ресурсами. Зачем тогда SLM, если мы все равно не сможем договориться?
          Примеры ответов в конкретных компаниях у меня есть. Рецептов – нет. Разве что один, но он вряд ли тебя устроит в силу своей общности: надо правильно формировать каталог услуг, понимая задачи и специфику организационной среды. Тогда таких коллизий будет меньше, и будут организационные механизмы для их решения. Все примеры – приватно.
          И ещё пара наблюдений. И предложений по изменению постановки вопросов.
          1. Любые договорные отношения требуют адекватности участников. На мой взгляд адекватных людей среди бизнес-подразделений достаточно. Уж точно не меньше, чем в ИТ-подразделениях. И они зачастую прекрасно понимают, что требовать все и прямо сейчас просто бессмысленно. Вопрос в другом: а ИТ-подразделение готово предложить перспективу: сейчас ограничения такие, но далее будем действовать так-то, и придём к такому-то целевому состоянию? То есть перевернуть позицию защиты в конструктив?
          2. Как я писал где-то раньше, сервисные отношения по своей природе являются отношениями, близкими к рыночным. Во внутренней среде при отсутствии конкуренции, при отсутствии связи “качество-вознаграждение” SLM просто может быть чуждым механизмом регулирования отношений. Поэтому я бы не утверждал, что в любой компании можно так все придумать, что SLM заработает. Вопрос в другом: а нужен ли данной компании (холдингу) SLM, если они как-то фатально не могут договориться? И какова причина того, что они не могут договориться?

          • Станислав Уштей

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

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

              “Ответ в общем универсален”

              Станислав, я немного запутался – это ответ на что?

              • Станислав Уштей

                На ваш вопрос: “Какова причина того, что они не могут договориться?”

                • Станислав Уштей

                  Эту тему, очень правильно описал Андрей Емелин в BPMS группе на Facebook в обсуждении статьи Коптелова А.”Совершенствование тоже требует автоматизации”:

                  “…Интересно. Считаю, что система изначально выстраивается так, чтобы принятие
                  управленческих решений этими топами находилось за пределами системы (это не
                  применимо к собственнику, он мыслит иначе). Таким образом, топ ставит
                  систему в зависимость от себя, исключая свою ненужность еë участникам. Это
                  дает ему возможность не следовать установленным в системе правилам,
                  сохранить свою “харизму”. Каждый ценен пока незаменим, а участие в системе
                  снижает его ценность. При этом топ один, два, несколько, создают свою
                  коалицию вне системы и следуя принципу “разделяй и властвуй над планктоном”
                  дарят участникам системы возможность реализовать в будущем релизе системы
                  новую версию ветвления процесса на этапах принятия управленческих решений и
                  так до бесконечности. Кто кого выживет, обычно это становится причиной
                  поиска линейными руководителями нового места работы, хотя не каждый
                  решается пойти на такой шаг. Такое только в Раше или не только, вот что
                  интересно…”

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

                    Абсолютно согласен. Поэтому топов надо включать в единую систему организационных отношений. Это может быть не очень нужно в рамках поддержки пользователей. Но для таких вещей, как CHG и SLM – жизненно важно, иначе они просто не будут работать как механизмы управления и принятия решений.

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

                  А-а-а-а 🙂

                  Ну бывает и так, как Вы говорите, и стены “колодцев” почти непробиваемы.

                  Но для базовых услуг (когда заказчиков несколько) я бы исходил не из вопроса “Что нужно конкретно этому заказчику?”, а “что нужно бизнесу?”. Если бизнесу действительно нужно, чтобы у этого подразделения почта была в режиме 12х7, то ресурсы найдутся, я уверен. Даже если при этом все остальные получат почту в режиме 12х7 сверх своих скромных требований. Если же бизнесу это не нужно или не очень нужно, должен быть организационный механизм, как сообщить это тому подразделению, которое требует больше, чем нужно бизнесу. Ключевой момент здесь – необоснованное увеличение расходов на ИТ. Организационные механизмы могут быть разные: от распоряжения большого босса или решения коллегиального органа управления до учета стоимости услуг в расходной части подразделений-заказчиков.

                  • Станислав Уштей

                    В условиях холдинга описанная схема реализуется через филиалы.

                    Кроме того, в принципе, эта задача решается через разделение услуг на бизнес-услуги – совпадающие с информационными решениями и операционные – производимые в рамках ИТ-процессов. Первые должны функционировать 24*7 (с учетом определенных окон простоев и уровня доступности), а вторые так как нужно для того чтобы сделать заказчику приятно (ну в обмен на блага конечно – тут поторговаться придется)

      • Вадим

        Воооот! У меня тоже постоянно крутится в голове мысль о наличии некоторого (неделимого?) комплекта базовых корпоративных услуг, что-то вроде типового набора мебели, если позволите такое сравнение )))

        Т.е. если ты сотрудник корпорации компании, то у тебя в обязательном порядке должны быть такие-то услуги (дворников, уборщиц и т.п. пока считать не будем): 2-4 кв.метра, стул, стол, лампа, набор лотков, ежедневник ))) компьютер, почта, то, сё… Грубо говоря, как у корпоративного винтика в корпоративном механизме.
        Плюс прикладные услуги, связанные собственно с содержанием работы: у юристов – Консультант и/или Гарант, у бухгалтеров – 1С или FI-модуль SAPa (и т.п.), у сейлзов – CRM, у трейдеров – торговые системы и т.д. и т.п.

        А раз это неотъемлемый базис, то и заказчиком его должна быть “компания в целом” (общекорпоративная служба заказчика выглядит наиболее приемлемым кандидатом, вот только где ее взять и как ее воспитать)))). При этом действительно проще организовывать и поддерживать такие услуги как определенные стандартом.

        так что с Дмитрием полностью согласен.

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

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

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