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

Service Desk снова всех спасает и выручает

В прошлую пятницу проводил игру Apollo-13. Как обычно, было интересно: это был корпоратив, поэтому все участники – из одной компании, однако никакого единства в команде не было. Если я правильно понимаю, в ходе реорганизации объединились несколько подразделений, плюс добавилось много "новичков", чему не очень рады "старички". Но сейчас не об этом…

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

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

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

Что было в игре: первая линия принимала "заявки" и частично их решала, передавая большую часть работы дальше. Вторая линия работала как бы наполовину – два сотрудника действительно пытались найти и предоставить решение, ещё два откровенно "перекидывали бумажки", не озабочиваясь ни судьбой конкретной заявки, ни судьбой игры в целом. Третья линия существенную часть времени торговалась с поставщиком, который торговаться не хотел – в итоге время шло, а решений инцидентов не находилось.

Так как я выполнял роль "пользователя", то весь end user experience мне был очень даже виден. Так как ещё одна моя роль – ведущий игры, то наблюдать за организацией и ходом работ было также весьма интересно и полезно.

Вот что я вам скажу: первая линия смогла если уж не спасти, то точно выручить остальных участников игры. Она работала сразу по нескольким фронтам: взаимодействовала с пользователем, пытаясь успокоить; взаимодействовала с менеджером, эскалируя срочные или важные запросы; взаимодействовала со второй линией и другими специалистами, пытаясь "продвинуть" зависшие задачи и добиться решения инцидентов, решённых плохо. Ей было тяжелее всех в организации, но именно из-за её усилий игра закончилась положительно и астронавтов вернули на Землю живыми.


Мой опыт на позапрошлом месте работы полностью подтверждает эти наблюдения. То, что мы называли тогда Help Desk, позволяло "вытянуть" качество наших услуг и добиться удовлетворённости пользователей, даже несмотря на задержки в решении инцидентов и прочие "пули над головой".


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

 

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

  • Leonid

    “Нет?” Да, согласен с выводом.

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

    Оборотная сторона медали – первая линя поддержки легко может “убить” [качество предоставляемых ИТ-услуг и] [уронить субъективную оценку пользователей об этом качестве].
    Тоже из личного опыта. 🙂

    • Полностью согласен.

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

  • Nick VanOrton

    Подписываюсь под каждым словом!

  • Максим

    Сложно не согласиться … но попробую!

    Может дело в том, что прочие процессы просто не дорастают до такого уровня, как интуитивно понятный Inc с функцией SD? Неужели когда в рамках Prb решают организационную или техническую проблему, уменьшая поток обращений, это менее значимое улучшение? Только, как справедливо было замечено одним из уважаемых авторов портала: “…рабочее управление проблемами вообще встречается редко…”. Может вопрос не в ценности рекомендаций, а в том, как их реализуют?

    • “Может вопрос не в ценности рекомендаций, а в том, как их реализуют”

      Возможно. Но вряд ли можно предположить, что рекомендацию “у всех взрослых ребят давно уже есть Service Desk” и рекомендацию “если контролировать изменения, то рисков станет меньше” можно принципиально по-разному реализовать, и что все обычно хорошо реализуют первое и не очень хорошо – второе.

      Мне кажется, что здесь дело именно в ценности рекомендации. Ну или большая часть дела.

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

    Дальше получается так:

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

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

    Просто, видимо, неприятный симптом “ИТ и пользователи друг друга не любят” – один из самых распространенных…

    • Вариант (4): порядка и процессов в ИТ было не много, но с появлением первой линии – прибавляется.

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

      Тогда мы возвращаемся к тому, о чём я писал в примере. Первая линия “делает жизнь лучше” по нескольким направлениям одновременно:
      1. Взаимодействие с пользователями. Это важно, об этом ты пишешь в самом начале про театр, и это уже даёт многое.
      2. Взаимодействие с экспертами – появляются стимул, контроль и очередность.
      3. Взаимодействие с руководством – эскалации, пинки, мини-отчётность. Любая приличная первая линия скажет кто ей мешает, а кто помогает, и скажет с цифрами в руках.

      Тонкий момент: первая линия – это точка контакта с пользователями. Значит, все эти условные деления на поддержку, эксплуатацию, сопровождение, разработку – это всё не важно. Важно – что ИТ даёт пользователю. И что он реально получает.

      Если при этом первая линия ещё и а) вежлива, б) помогает и решает проблемы, а не только передаёт, то приведённые тобой примеры улучшений вряд ли перевесят значимость организации Help Desk.

      А когда айтишники догадаются использовать Service Desk не только на вход, но и на выход… Оповещения, опросы – имидж ИТ может вырасти на сотни тысяч миллионов процентов!

      А когда первая линия истребует себе пусть простой, но всё же портал для пользователей… Контроль хода работ по заявке, бланки обращений, эскалация по щелчку мыши – это точно +100500 к карме ИТ!

  • Георгий

    да. согласен полностью.

  • Вадим

    Да, НО…
    IMHO провокационная формулировка вопроса, т.к. качество услуг не определяется единственно реагированием на обращения (инциденты, запросы и т.п.), а построением и отлаженностью всей услуги. конечно , SD может прикрыть нерадивого администратора, вовремя (упредительно) не сделавшего свою работу в трюме, что привело к некоторому инциденту и решении вопроса в срочном порядке, чтобы не уронить лица (= качества обслуживания). Но работу-то должен сделать этот администратор, а не SD, не так ли? (опять же это зависит от сути необходимой работы – SD элементарно может не быть компетентен в ее выполнении, но может отлично контролировать ход выполнения по некоторому графику)

    • “провокационная формулировка вопроса” – возможно, провокация в том, что та самая “мелочь”, которой все консультанты уже устали заниматься, и которая должна быть в любом приличном ИТ-подразделении, называемая Service Desk – эта самая мелочь вдруг выдвигается на номинацию “самая лучшая рекомендация ITIL вплоть до версии ITIL 2011 включительно”. Это да, видимо, провокация.

      А по сути – верно, SD не сделает работу за нерадивого администратора. Я же не об этом – SD может смягчить, структурировать, и выступить лицом и т.д. Это хорошо. Это – годный совет из ITIL.

      Вопрос – есть ли ещё такие же годные советы?

      • Георгий

        ах вот в чем вопрос был? 🙂 т.е. где та вторая дельная вещь? 🙂

        • Ага. И есть ли она вообще 🙂

          • Георгий

            Есть! но тебе опасно говорить – ты сразу разболтаешь всем и все… сказка кончится 🙂

            • Ок, буду мучиться, пока не расскажешь как-нибудь при встрече. Я постараюсь хотя бы час-другой потом помолчать 🙂

              • Георгий

                Можно конкурс устроить 🙂 победителю самый ценный приз – рассказ про третью бонусную ценную идею ITIL 🙂

        • Вадим

          вторая вещь – услуги!
          типа, бросьте все – предоставляйте услуги :о)))

  • Pavel Solopov

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

    • Да какая там глубинная суть, всё на поверхности 🙂

      Нет, речь не про энтузиастов. На них правда далеко долго не уедешь.

      Речь именно про первую линию как первый и единственный шаг к наведению порядка в ИТ. Как следствие – да, на первой линии начинают работать “адекватные” люди, а не как обычно 🙂

  • Pavel Solopov

    Как следствие — да, на первой линии начинают работать «адекватные» люди, а не как обычно

    это утверждение мне кажется сомнительным, нормальные люди, как правило не следствие, а причина порядка. Или я вас, Олег, не верно понял?

    • Какая в данном случае разница что причина, а что – следствие? Мне кажется, это совсем не важно.

      Под адекватностью людей я имел ввиду не столько их личные качества (не бросаются на людей, работают работу и т.д.), сколько адекватность с точки зрения пользователя. Зачастую именно с точки зрения пользователя в ИТ работают какие-то маргиналы, которым дела нет до реальных проблем, а голова забита техническим мусором.

      • Pavel Solopov

        Точнее в голове пусто. 🙂

        • Да, бывает и так. Но не могу сказать, что часто. Вот чего айтишникам традиционно недостаёт – это той самой клиентоориентированности.

          • Pavel Solopov

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

            • Снова уходим в сторону от темы, куда-то в общефилосовские вопросы…

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

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

              Давайте уже ближе к поставленному вопросу: есть в ITIL ещё что-то настолько же полезное?

              • Pavel Solopov

                Ну так это же частнй случай, Олег, в одной компании к рекламщикам вопросов было меньше чем к ИТ. А вдругой наоборот. Ну да ладно, не буду уводить вас от темы. Обсуждайте. 🙂

                • Конечно, частный. А у Вас есть статистика? 🙂

                  • Pavel Solopov

                    Нет, но это вы, Олег, заявили: “Вот чего айтишникам традиционно недостаёт — это той самой клиентоориентированности.”
                    Я думал у вас есть статистика, которая указывает на традиционность. 🙂

                    • Так уж вышло, что я много айтишников видел. Кажется, могу обобщать 🙂

                      А снабженцев и электриков – немного, тут без статистики никак 🙂

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

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

  • Анатолий

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

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

    Действительно, прослушивая множество записей разговоров, убеждался, что если бы пользователи вели себя, в некоторых случаях, таким образом со специалистами 2 и 3 линий, проблем было бы значительно больше.

     С выводами согласен.

     


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

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

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM