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

Размышления на тему сервисного подхода

Опубликовано 22 мая 2013
Рубрики: ITIL, ITSM, SLA, SLM, BRM, Аналитика: точка зрения
Комментарии

Коллеги, обобщив опыт нескольких предыдущих проектов на тему управления уровнем ИТ-услуг, вебинаров, дискуссий, заметок на портале, я написал довольно большую статью с неоригинальным названием «Управление уровнем ИТ-услуг». Статья состоит из двух частей:

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

Мне лично результат показался интересным – есть, над чем подумать, есть, что обсудить. К обсуждению приглашаю вас – посетителей портала realitsm.ru. Думаю, здесь найдется немало людей, кому есть, что сказать на затронутую тему.

Искренне Ваш, ДИ.

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

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

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

  • Анатолий Павлюченко

    Отлично структурировано!

    В первой части не встретил ничего, что бы готоворило о таком понятии как "Зрелость" (в явном виде. Я понимаю, что всё крутится вокруг этого). Различные аспекты такого понятия могли бы пополнить (или расширить) набор тезисов для обсуждения трудностей и преимуществ.

    Во второй части так и хочется увидеть примеры _целей проекта_ и _групп заинтересованных лиц_. Это бы прекрасно сочеталось с первой частью. Так и вижу пример поснительной записки и Executive Summary. Возможно, в виде ссылок на шаблоны документов…

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

      В первой части не встретил ничего, что бы готоворило о таком понятии как "Зрелость" (в явном виде. Я понимаю, что всё крутится вокруг этого)

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

      • Анатолий Павлюченко

        Я приблизительно это и имел в виду, когда говорил, что "…крутится вокруг этого". Попробую сформулировать таким образом: от анализа самого сервисного подхода мы во второй части преходим сразу к самому проекту, начиная с определения целей. Т.е. _момент принятия решения_ остаётся "за кадром". Да, в заключении первой части есть посыл к ИТ-руководителям. Возможно это не так уж и важно для последовательности изложения, однако, на мой взгляд, его можно конкретизировать (стимулировать) предложениями по анализу зрелости ИТ организации, например.

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

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

          Возможно это не так уж и важно для последовательности изложения, однако, на мой взгляд, его можно конкретизировать (стимулировать) предложениями по анализу зрелости ИТ организации

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

          • Анатолий Павлюченко

            Позволю себе не согласиться с такой точкой зрения. Стадия аудита или обследования – это один из стандартных этапов де факто для почти любых проектов в любой отрасли. Тем более, что в неявном виде это указано в статье, как Вы сами и указали выше.

            И, кстати, я не писал о "факторе для принятия решения", а лишь про отсутствие самого момента.

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

              Позволю себе не согласиться с такой точкой зрения

              Конечно. Мы это только приветствуем 🙂 В диалоге рождается истина.

              Стадия аудита или обследования — это один из стандартных этапов де факто для почти любых проектов в любой отрасли.

              Бесспорно. Но ключевой вопрос в другом – вы проводите обследование в рамках проекта до принятия решения о его инициации или на основе принятого решения? Дело в том, что CIO определяет программу развития не на основании текущего уровня зрелости, а на основании стратегического видения целевого состояния. Текущее состояние дел скорее является ограничением при постановке задачи (вспомните зону ближайшего развития по Выготскому) и фактором, определяющим  выбор оптимального способа достижения цели. В этом смысле Вы абсолютно правы – анализ текущего состояния необходим. Но опять же – скорее не анализ уровня зрелости, а SWOT, это существенно более полезный инструмент, который мы действительно активно используем в проектной практике.

  • Nargiza Suleymanova

    Дмитрий, кажется, во второй части рисунки 1 и 2 нужно местами поменять.

  • Andrey Kapustin

    Дмитрий, спасибо. Действительно хорошо структурировано: все знакомо, но взгляд со стороны ITSM-внедренца (для меня сейчас) очень интересен.

    Может мне кажется 🙂 но похоже "ломка копий" вокруг "что такое сервис?" поутихла. Теперь все дружно концентрируемся на методике формирования каталога?

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

      Теперь все дружно концентрируемся на методике формирования каталога?

      Да, мне эта тема кажется вполне достойной. Но … основные ответы уже есть, а детали – специфика не методики, но конкретного проекта. Гораздо интересней для меня тема проведения оргизменений, связанных с сервисным подходом – изменение позиции, поведения и культуры людей. В части SLM это сложно не только в силу "размера" изменения (сколько всего меняется), но и потому, что это очень медленное изменение, а управлять медленными изменениями гораздо сложнее, чем краткосрочными. Кроме того, менять надо с двух сторон – это еще один фактор сложности. Вот это действительно интересная тема, я бы с удовольствием нашел здесь собеседников, которым есть, что сказать по этому поводу.

      • Павел Солопов

        Ещё не в пользу сервисному подходу играет возрастающие при его применении издержки на внутренние коммуникации. Для некоторых бизнесов это может быть очень критично. Это как если бы во время боя командиры, допустим, рот вместо исполнения приказов командира полка, взялись бы с ним договариваться.

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

          Это сравнение очень хромает, на обе ноги 🙂 Командиры верхнего уровня полностью распоряжаются подчиненными ресурсами, поэтому могут отдавать приказы. Директор по финасам и логистике (к примеру) не полностью распоряжаются ресурсами ИТ. Поэтому отдавать приказы здесь не получится. А придется договариваться. И неважно, будете Вы говорить слова "услуга", "сервисный подход" или нет – договариваться придется.

          • Pavel Solopov

            Что вы имеете в виду Дмитрий, под "полностью распоряжается рескрсами"?

    • Pavel Solopov

      похоже "ломка копий" вокруг "что такое сервис?" поутихла

      Ну почему же поутихла? Это я давно не заходил в гости на реалитсм.

      🙂

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

        Ну и…. ?

        • Pavel Solopov

          Подождите, Дмитрий, я только начал читать.

          Вот пока до определения ИТ-услуги дочитал. Собственно его надо как-то уточнить.

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

          Из этого определения никак не следует нематериальность ИТ-услуги, что вы собственно подтвержадете и сами, предлагая в качестве примера услуги аренду оборудования. В чём тогда отличие ИТ-услуги от товара? В соответствии с этим определением, когда вы купили сервер, допустим, то производитель обеспечил для вас возможности использования технологий для эффективности и устранения? Обеспечил. Значит он оказал вам услугу, а не продал вам товар… Выходит так если по определнию.

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

          • Роман Журавлёв

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

            Что же до продажи сервера, то я бы все же рассматривал  предлагаемое определение ИТ-услуги как дополнение-уточнение к определению услуги вообще. Которое в ITIL вполне себе подходящее. Тогда вариант продажи товара из рассмотрения исключается еще до того, как мы начнем определять ИТ-специфику. 

            • Pavel Solopov

              Насчёт аренды, тут я с вами Роман не согласен. Многое из названного вами детали конкретного договора и местного законодательства. если вы берёте что-то в аренду, это ещё не означает, что вы не берёте на себя обязательства по его ремонту. Те же налоги, в России вы не платите налог на имущество для арендованных активо, но не могу с уверенностью утверждать. что аналогичная ситуация и в других странах.

              Ну а страхование, так это и подавно. Даже в том же примере с арендой автомобиля, очень часто страховка в стоимость аренды не входит, это доп опция. А если у вас ещё что-то и сломается, то не факт. что с вас не потребуют возместить стоимость ремонта. Я как-то решил почитать условия договора. был искренне удивлён…

              Поэтому основное принципиальное отличие аренды от приобретение, это её срочность. Приобретая что либо вы плучаете данный объект в бессрочное распоряжение, а арендуя только во временное, но и только за часть стоимости.

            • Pavel Solopov

              Проблема "подходящего" определения из ITIL в том, что оно оперирует неконкретным понятием "специфические затраты и риски". И затраты и риски присущи всем возможным вариантам, и во всех случаях их можно назвать специфическими. Вот опять же про тот самый сервер.
              Заказчик покупает готовый сервер у известной (или не очень) компании почему?

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

              Я бы в этом определении оперировал не владением рисками и затратами, а владением средствами производства (средствами удовлетворения потребностей).

  • Andrey Kapustin

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

    В проекте, в котором работаю, наблюдаю следующую картину:
    – ITSM декларирован на (высоком) уровне со стороны Заказчика; формально внутренние IT подразделения Заказчика на уровне политик/регламентов работают по ITSM
    – Аутсорсеры(вендоры-подрядчики) работают также (формально) по ITSM: в ключевом соглашении, использующемся для подписания конкретных проектных контрактов содержатся не просто ссылки на ITIL, но и практически цитаты из него; в нем же пристуствует подобие Service Catalog, однако сам термин не используется ( …разбираюсь почему 🙂 )
    При этом надо понимать, что для IT аутсорсера собственно услугой, предоставляемой Заказчику, являются по сути элементы IT процессов, ну или процессы целиком в том понимании, которое дано в ITIL; например услугой будет Functional Analysis, как часть Change Management.
    В целом о каталоге услуг аутсорсера я ничего нового не сказал: собственно тот же подход виден в http://www.realitsm.ru/2013/05/autsorsing-prinesite-menyu-pozhalujsta/.

    Но ведь с другой стороны, подобного рода каталог весьма далек от Бизнеса Заказчика. Простройка Каталога от бизнес-процессов – вот что декларирует ITIL.

    В текущем моем проекте, как отмечал в другом посте, каталог(список) услуг есть и он был построен от бизнес-процессов. Однако, как и было отмечено, формирование каталога шло витиеватым путем, потому что… и тут вернусь к обозначенной в вашем посте теме:
    1. SLM(да и вообще ITSM) – это не (только) формальная процедура/инстурмент/политика/т.д., это подход, требующий соответствующей (корпоративной) культуры; написанные регламенты никогда не научат работать по ITSM`у людей, которые не готовы (или вообще не в состоянии) принять суть данного подхода
    2. (если вспомнить еще в придачу модель Коттера из последнего вэбинара то) Переоценить значение лидера и команды, продвигающей SLM(да и вообще ITSM) в проекте/подразделении/компании не получится: в текущем проекте вижу отдельных таких людей на стороне Заказчика, но их действия разрозненны и фрагментарны, лучшее успешно вязнет и растворяется в инертном большинстве, привыкшем отвечать только за свое звено в процессе.
    3. (то что должно стоять в начале списка) Поддержка высшего руководства – она должна быть.

    В целом подвожу к тому, что Вы уже, Дмитрий, указывали и я с Вами солидарен: наличие Каталога(хотя бы от систем) еще не свидетельство ITSM, однако (как минимум) декларация намерений. От себя: отсутствие Каталога от бизнес-процессов не свидетельство отсутсвия ITSM.
    И еще одна мысль: мне кажется, что внедрение SLM для большинства Заказчиков – это существенное орг.изменение. Как Вы думаете, Дмитрий, насколько лет еще работы в этом направлении ? (риторически)

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

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

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