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

Все и сразу?

Опубликовано 31 марта 2014
Рубрики: ITIL, ITSM, SLA, SLM, BRM
Комментарии

Книга «Каталог услуг для успешного управления ИТ», последующее интервью с одним из ее авторов Троем Дюмуленом и анализ ряда проектов 2011-2013 годов помогли мне еще раз сделать один очень важный вывод: сервисный подход гораздо шире, чем SLM. SLM по сути – это контрольный механизм, который на системной основе позволяет обеспечить контроль качества услуг, то есть оценку достижений в сравнении со взятыми на себя обязательствами. Но чтобы научиться брать на себя измеримые обязательства надо сначала научиться формулировать свою работу в терминах ценности для заказчика, а затем научиться ее измерять. Опыт показывает, что и первое, и второе – действительно сложные задачи для большинства компаний, и на их решение требуется время. В том числе поэтому в ITIL v3 произошло отделение процесса управления каталогом услуг от SLM.

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

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

Здесь можно провести аналогию с тем, как в организации рекомендуется вводить премирование / депремирование сотрудников на основании KPI: сначала разработка KPI и сбор данных о текущем уровне производительности, затем определение целевых значений, затем пробный расчет пока без фактического влияния на зарплату и лишь затем включение фактического влияния.

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

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

  • Не очень понятен финальный вопрос.

    Вы готовы ждать, отказавшись от планов «заключить SLA до конца года» (тем более, если эти планы спущены вам сверху)? И что делать, если вы не готовы?

     Чего ждать? Пока созреют условия для SLM? 

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

     

    Или я неверно понял вопрос?

    • Или я неверно понял вопрос?

      Вопрос понят верно. Ответ, собственно, тоже понятен. Но хотелось бы ответов и от других людей, в том числе от тех, кому приходилось получать директиву "заключить SLA до конца года". Потому что одно дело знать, а другое – принимать решение.

  • Дмитрий, вы так пишете про "спускается сверху" как будто это что-то плохое =)) А как же management commitment?!

    Я видел  успешную реализацию ускоренного "взросления" сервисной организации именно когда у директора по ИТ было видение, вес среди бизнес-руководителей и энергия. Он "спустил сверху" план создания каталога и практик SLM, нашел под это дело людей и т.д.. Незрелая ИТ-организация стонала, зрелые заказчики щурились, но он лично заключал SLA, и вдумывался в показатели качества, и инвестировал в мониторинг, и участвовал в service review, и принимал на основе сервисной отчётности решения (по ресурсам, в частности).

    Мне кажется, без такого локомотива ждать придётся бесконечно долго. Или вы не такой "верх" имели в виду?

    • Мне кажется, без такого локомотива ждать придётся бесконечно долго.

      В точку.

    • Костя, чтобы описываемый Вами кейс обрел значение, прошу ответить на несколько вопросов:

      1. Сколько времени ушло на это "скоренное взросление"?

      2. Каков масштаб компании (отрасль и оборот, общая численность персонала, ИТ-персонал, территории)?

      3. Каких результатов в итоге удалось добиться?

      • 1. полгода до первой редакции SLA с заказчиком (customer-based). Ещё полгода до первый service review с нехилым SIP.

        2. розничная торговля, лень искать, 10000 человек, 150 человек, 50+ регионов РФ.

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

        Из минусов нужно отметить трезвую ограниченность масштаба сервисных отношений: они выстраивались только с ключевыми бизнес-подразделениями.

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


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

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

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM