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

Многоликие услуги: чего изволите?

Опубликовано 11 мая 2012
Рубрики: ITSM, Аналитика: точка зрения
Комментарии

Какая это, оказывается, бездонная тема – идентификация услуг. И как много зависит от принятого решения…

За последний месяц мы много об этом говорили – Дмитрий в своем вебинаре (да, теперь наш робот знает это слово!), хотя тема, казалось бы, была от определения услуг далека; я в заметке про структуру услуг и вчерашнем вебинаре; а уж какая развернулась дискуссия вокруг концепции построения каталога услуг! 

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

Вот эта пара слов:

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

 

В общем, навязанные услуги – это плохо. И это справедливо не только для конкретных услуг, но и для всего сервисного подхода. 

ОБУЧЕНИЕ
IT Service Management
Учебные курсы от соавторов ITIL 4

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

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

  • Андрей Капустин

    Роман,
    Как (под каким маркетинговым соусом) Вы (Ваша компания) продаете заказчикам (Бизнесу), что сервисный подход им нужен? То есть какие есть очевидные доводы, что без сервисного подхода Бизнес скорее проиграет чем выиграет?
    Или зайду с другой стороны: в каких случаях сервисный подход не нужен или вредит Бизнесу?

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

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

      Но бывает, что именно сервисный подход – то, что надо. Когда мы вместе с заказчиком в этом уверены, мы помогаем его применить. Об этом – недавний пресс-релиз (http://www.cleverics.ru/ru/about/news/366-raiffeisen-strategy).

      • Андрей Капустин

        Роман,
        Из пресс-релиза вынес следующее: если компания клиентоориентированная , то сервисный подход как раз для нее.
        Понимаю, что далеко не все Российские компании с формально заявленной клиентоориентированностью таковыми являются.
        В связи с чем хочу вернуться ко второй формулировке моего вопроса:
        В каких случаях сервисный подход не нужен или вредит Бизнесу?

        Сорри за въедливость, но мне сейчас Сервисный Подход кажется серебряной пулей, хотел бы избавиться от этой иллюзии.
        Подозреваю, что застрагиваемая принципиальная тема границ приенимости подхода должна разбираться в первоисточниках( ITIL, Cobit ?) или на курсах. Что бы порекомендовали почитать/посетить?

  • Олег Скрынник

    Прекрасная иллюстрация. Победа в номинации слоган года 🙂

    • Капустин Андрей

      Олег,
      Можно Вас тоже попросить прокомментировать ветку с моими вопросами. Интересно ваше видение.

      • Олег Скрынник

        Андрей, очень лестно, что Вы интересуетесь моим мнением. Теперь точно придётся отвечать 🙂

        Полагаю, что речь вот об этом вопросе:
        “В каких случаях сервисный подход не нужен или вредит Бизнесу?”

        Мне кажется, что есть две яркие ситуации, когда, извините, “внедрение” сервисного подхода пойдёт не на пользу, а во вред.

        1. Компания организована по жёстко иерархическому принципу (например – большинство гос.компаний). Сервисная культура будет чуждой в такой среде, шансы для неё закрепиться очень невелики, польза – сомнительна.

        2. Сервисная культура насаждается через силу, не имея поддержки и понимания как со стороны бизнеса, так и со стороны ИТ. В этом случае очень велика вероятность отторжения, вплоть до саботажа, опять же – при неясных выгодах и перспективах.

        Андрей, я позволю себе порекомендовать Вам давнишнюю статью “Призрак ITSM. Что было до и что будет после” за авторством меня и Романа Журавлёва, в которой затрагивается вопрос сервисного подхода – http://www.cleverics.ru/ru/subject-field/hot-issues/ghost-of-itsm

        Более того, я готов анонсировать новую статью Романа под названием “Компьютер как услуга: почему не приживается сервисный подход”. В полном виде она пока не опубликована, мы ждём публикации в ближайшие месяцы. Но если Вы будете на конференции ОСП 24 мая (http://www.realitsm.ru/2012/05/osp-2012/), думаю, Вам достанется экземпляр 🙂

        • Andrey Kapustin

          Олег, спасибо за ссылки.
          На конференцию только что получил подтверждение регистрации 🙂

  • Pavel Solopov

    Ещё бы добавил сноску к п.1
    “Наличие процесса управления инцидентами ещё не означает применения сервисного подхода”

    Ибо часто ставят знак равенства, от чего возникает некоторое недопонимание.

  • Pavel Solopov

    Одностороннее применение сервисного подхода поставщиком услуг (“догонять и причинять добро”), скорее всего, никому не доставит пользы и удовольствия.

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

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

      Павел, а расскажете подробнее про сервисный подход для внутренних нужд? Спасибо!

      • Pavel Solopov

        А про что Вам, Роман, именно рассказать?
        Про то, что разные подразделения внутри ИТ тоже могут взаимодействовать друг с другом по принципу предоставления сервиса, что сделает взаимодействие более предсказуемым, прозрачным и приятным.
        Или о том, что “определить сервис” ещё значит и описать технологическую схему и построить дерево отказов, что тоже совсем не лишнее для производственной деятельности ИТ.

        Тут надо отметить, что у нас с вами есть некоторые отличия в ментальном подходе к ИТ-сервису. Отсюда может возникнуть некоторое недопонимание. 🙂

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

          А почему именно услуги?
          Более предсказуемым, прозрачным и приятным взаимодействие могут сделать согласованные сторонами регламенты взаимодействия. Если нужно специфицировать предмет взаимодействия – в большинстве случаев сгодятся ИТ-системы или даже отдельные компоненты (продукты, как их называет Максим). Какова дополнительная ценность от применения именно сервисного подхода при наведении порядка?

          • Pavel Solopov

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

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

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

              …если только это не взаимодействие при управлении инцидентами?

              (“Наличие процесса управления инцидентами ещё не означает применения сервисного подхода”)

              • Pavel Solopov

                Тонко бьёте, Роман. В угол загоняете. 🙂
                Но ваше предположение не совсем верно.

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

  • Alexander Peshkov

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

    • Pavel Solopov

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

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

      • Alexander Peshkov

        Спасибо, отличный вопрос.
        Теория и здравый смысл говорят нам, что если нет потребления – нет и услуги.
        Организовывать работу, конечно, нужно. Вопрос только в том, на какие цели вы будете ориентироваться? Если нет потребления, нет SLA, то значит, эти цели определены экспертным образом (например, каталог услуг, в котором выданы параметры сервисов по-умолчанию). Это к вопросу про углы, заклеенные SLA вместо обоев. Вы в любом случае должны опубликовать свои экспертные оценки, иначе по первому же инциденту вам придется отвечать – почему именно час на реакцию, а не пять минут? И если вы построили работу исходя из экспертной оценки (которая еще и не опубликована), то возможно, вы и ресурсы запланировали неправильно. А это уже не так просто исправить.
        Я не хочу сказать, что организация работы – это плохо, совсем нет. Я даже полностью согласен, что это в любом случае хорошо. У меня только сомнения относительно того, что при организации работы есть веские причины не учитывать мнение потребителей. В конце концов, Каталог услуг с уровнями сервиса по-умолчанию, это не так и сложно. С другой стороны – это диалог и адекватные ожидания. + возможность при организации работы так же и адекватно запланировать ресурсы.

        • Pavel Solopov

          У меня только сомнения относительно того, что при организации работы есть веские причины не учитывать мнение потребителей.

          Я разве об этом говорил? Я говорю о том, что если у вас не сервисные отношения с пользователями (причин мы не рассматриваем), то это не значит, что вы не можете использовать сервисные отношения внутри.

          А ориентир для ИТ давно известен: чтобы всё всегда работало. 🙂

          • Alexander Peshkov

            Павел, откройте же наконец тайну, почему же нет отношений с пользователями? Т/е зачем строить систему управления (а вы предлагаете сделать именно это, наладив регламенты между группами поддержки), в ситуации, когда нет конечной цели этой системы. “чтобы все всегда работало” звучит несколько утрировано, так что можно рассматривать как некий момент эпистолярного творчества, но не как ориентир. С таким ориентиром можно зайти далеко, но не факт, что туда куда нужно.

            • Pavel Solopov

              Александр, я от вас ничего не скрываю. Все мои высказывания и рассуждения основываются исключительно на начальных условиях.
              Роман написал:
              •Для того, чтобы сервисный подход принёс пользу, его нужно принимать и применять с двух сторон — заказчика и поставщика услуг.
              Одностороннее применение сервисного подхода поставщиком услуг (“догонять и причинять добро”), скорее всего, никому не доставит пользы и удовольствия.
              Т.е. предполагается, что применение сервисного подхода между поставщиком и заказчиком почему-то не возможно, я не знаю почему (это начальные условия воспринимаемые мной здесь как данность. Может у главного заказчика алергия на Сервис, рвёт его при каждом этом слове. 🙂 ).
              Я же говорю о том, что даже если сервисный подход не применяется между поставщиком и заказчиком, то поставщик может получить выгоды от применения такого подхода внутри себя.
              Т.е. даже если отношения с заказчиком или бизнесом, как угодно, строятся даже по принципу “чтобы всё работало”, это не отменяет возможности применять сервисный подход внутри ИТ, и он тоже даст свои результаты. Как вариант спокойствие главному ИТ-ишнику (некоторое спокойствие 🙂 ).

              • Alexander Peshkov

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

                • Pavel Solopov

                  но он сильно нужен?

                  Да, действительно! Давайте уволим генерального директора по рекомендации начальника ИТ-отдела. 🙂

                  • Alexander Peshkov

                    Да уж, с инсорсингом всегда сплошные проблемы 🙂
                    Никакой ГД не будет против определить список того, что делает ИТ (это голубая мечта любого ГД, у которого есть свой ОИТ, не так ли?). Список может включать и пункт “прочее” (чтобы ГД не боялся, что айтишники потом это “прочее” делать не будут).
                    Т/е, возможно, постановка вопроса изначально не полная, пользователи-то могут и не хотеть сервис, но причинять его им все равно нужно (просто незачем говорить, что именно мы им причиняем).

  • Alexander Peshkov

    В принципе, было бы круто договориться о том, что такое сервис, чтобы это понимание было единым, как минимум, у всех читателей данной ветки:
    1. Сервис – это предоставление ценности клиенту без владения …. и тп.
    2. Сервис, композиционно – совокупность инфраструктуры, спецификации качества и поддержки.
    3. Сервис – одновременно и предоставление и потребление.

    Как-то так, видимо. Многоликий он наш 🙂

    • Pavel Solopov

      чтобы это понимание было единым, как минимум, у всех читателей данной ветки

      Скорее это станет основной темой обсуждения в этой ветке.

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

        Ах, Павел, если бы только в этой… =)))))

        • Alexander Peshkov

          Реальность – есть продукт договоренности 🙂

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

            Круто. Такие вещи надо записывать или хотя бы запоминать. Достойно пера Курта Воннегута 🙂

            • Alexander Peshkov

              В оригинале, кажется, это “продукт согласия”, что люди согласились считать реальным – то и реально. Радстараца 🙂

      • Олег Скрынник

        Давайте не будем! Ну пожалуйста!

        Нельзя же каждый вопрос сводить к определению единственного понятия.

        • Pavel Solopov

          А это, Олег, знаете как в фэнтези. у каждого дракона есть его истинное имя. Узнаешь его, и победишь дракона. 🙂
          Вот мы его всё ищем и ищем…
          Дракон скоро сам уже издохнет от тоски, а мы всё ищем и ищем… 🙂

        • Alexander Peshkov

          Я столкнулся с тем, что такой простой вопрос имеет фундаментальное значение. По личному опыту, после того, как мы у себя здесь договорились, что такое есть Сервис, то итсм-изация организации пошла намного проще и быстрее.
          Т/е если все мы применяем термин в одном и том же смысле, то не возникнет на пустом месте куста крыжовника вместо стройной логический линии (будь то процесс или ветка в борде) – такое вот незатейливое мнение.

          • Олег Скрынник

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

            • Alexander Peshkov

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

              Впрочем, план, честно говоря, был другой, просто запостил свою мысль, так сказать, подлил каплю масла в огонь. Хотя, мысль-то мне понравилась! 🙂

        • Георгий

          Олег, это невозможно. с 2004 года я понял одну истину, если собирается более 3 сервис-менеджеров “почти мирового уровня” в одном месте, они обязательно будут спорить и рассуждать о том, что такое сервис 😀
          Это не остановить 🙂

  • Stepan Taborovets

    Широко используется мантра “процессно-сервисный подход к управлению ИТ”
    А можно ли упорядочивать деятельность ИТ используя просто процессный подход?
    Мне кажется, именно про это говорит Павел

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

      За Павла не отвечу, а я так точно про это 🙂

    • Pavel Solopov

      Осталось выяснить отличия Процессного, Сервисного и Процессно-Сервисного подхода. 🙂
      А для этого надо сформулировать признаки каждого из них.

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

        Паша, неужели Вы ещё не сформулировали? Что же здесь непонятного?

        • Pavel Solopov

          Чтобы дискутировать не достаочно выяснить для себя. Надо договориться с оппонетном. А я большой оригинал в части оперделений, поэтому опасаюсь недопонимания. 🙂

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

      “А можно ли упорядочивать деятельность ИТ используя просто процессный подход?”

      Ну разумеется. Мы уже здесь обсуждали эту тему: http://www.realitsm.ru/2011/09/itsm-as-a-medicine/

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

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

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