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

ИТ-поддержка топ-менеджеров – как правильно?

Самая обсуждаемая ITSM-статья последних дней: гостевая публикация Симона Морриса на портале itsmreview.com

Симон рассуждает на важную для многих тему: как правильно организовать поддержку пользователей категории VIP?

Существуют два совершенно разных взгляда на вопрос:

  1. Пуританский. Обслуживание важных персон на экстремально высоком уровне возможно только за счёт снижения качества предоставления услуг кому-то другому (иначе говоря, всем остальным пользователям). Поэтому допускать "VIP-сервиса" не следует.
  2. Прагматичный. Нам приходится отчитываться по уровню предоставления услуг перед бизнесом. Даже если по отчётам всё выглядит неплохо, недовольный топ-менеджер может поставить ИТ-службе неудовлетворительную оценку, на основании только личного негативного опыта. А может быть и наоборот: довольный тем, как обслужили его личное ИТ-оборудование, VIP-сотрудник сможет закрыть глаза на наши прочие недостатки. Поэтому следует привлекать все доступные ресурсы для того, чтобы решать вопросы у VIP-пользователей как можно скорее и качественнее.

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

Его личный рецепт – замена Very Important Person на Very Important Role:

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

В одной из компаний, в которых я работал, мы дошли и остановились на уровне 5% сотрудников, занимающих такие "важные роли", и настроили свою ITSM-систему соответствующим образом.

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

Подробные выкладки и примеры от Симона, читайте в его статье.

А как к решению вопроса VIP поддержки подходите вы? Поделитесь в комментариях!

«VAP: Управление уровнем услуг и каталогом услуг»
Разработка каталога, SLA, метрик качества, расчёт доступности

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

  • Pavel Solopov

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

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

  • Георгий

    Конечно же ролевой принцип.
    Во многих проектах, так и делали, тк далеко не всегда и не везде ТОП приоритет у заявок ТОП-менеджемента. Как это ни странно может быть прозвучит, в некоторых случаях заявка от ТОП-менеджера (или его секретаря) имеет существенно более низкий приоритет, чем у сотрудника, стоящего формально в вертикали управления существенно ниже, но выполняющего более важную для компании задачу в данный момент (или всегда) 🙂
    Безусловно есть компании с жесткой вертикалью и с такими жесткими отношениями в приоритетах, но и там это некий “ролевой” принцип, тк есть секретари, есть персональные замы, есть “команда” ТОП-менеджера, которая обладает таким же или близким к такому же статусу для ИТ

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

  • Используем и роли, и VIP.
    Роль влияет на сроки и приоритет обработки обращения. Причём в зависимости от услуги. Например, брокеру важно, чтобы работала торговая платформа и потоки котировок. Это мегасрочно. Но обращения по другим поводам (корпоративный портал, ms word) такой срочностью не обладают.
    Признак VIP прямо на сроки не влияет. Он в основном для иллюстрации (“посетитель непростой”), плюс в некоторых процедурах (в первичной поддержке, в закрытии) у VIP’ов есть свои особенности.

    • Pavel Solopov

      Признак VIP прямо на сроки не влияет

      Это, если честно, это какой-то самообман: Признак ВИП на сроки не влияет, просто отнеситесь к его заявке внимательно. Просто чуть более внимательней, и как можно быстрее…
      🙂

      • Нет, я же говорю – вопрос не в скорости, а в том, что какие-то шаги процедур опускаются или меняются по сравнению с “обычным” пользователем. Основная идея здесь – сделать более комфортным режим взаимодействия с ИТ-специалистами. А сроки – это к ролям (VIP-сотрудник также может принадлежать к такой роли, но может и не принадлежать).

        • Георгий

          Да, в одной известной системе прямо из коробки есть подобное – тип пользователя, не помню как точно его назвали, что то типа Sensitive чтоли ) назвать это VIP тоже любопытная идея

          Вообще разные роли – очень правильно, тк их всегда больше чем 2 (VIP и неVIP) и, конечно, важно по какому сервису обращение, я, как обычно коряво, но именно это и имел ввиду

        • Pavel Solopov

          Вообще, автор статьи нам предлагает игру словами, конечно. давайте заменим VIP на VIR… Но подход, названный им, пуританским вовсе не отменяет наличие ролей с различным уровнем обслуживания для них. Вопрос в другом: преобретает ли пользователь приоритет в обслуживании, только потому, что он занимает определённую должность
          Или имеет значение его влияние на бизнес (кстати, кто должен определять это влияние).

          И повторюсь, мой опыт показывает, что руководство всегда обслуживается по отдельной категории, даже если нет признака VIP. Руководство надо знать в лицо! 🙂

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

            “Или имеет значение его влияние на бизнес” – конечно. Только никто не ставит задачу определить влияние на бизнес каждого пользователя, этот абсолютизм ни к чему. А вот выделить из всего предприятия тех, кто реально важен, достаточно легко в каждом конкретном случае. Пример: в одной компании к VIP с т.з. Help Desk были отнесены диспетчеры, формирующие отгрузку вагонов с продукцией. Должность маленькая, ЗП не сравнима с высшим руководством, но все их обращения отрабатывались скорейшим образом согласно регламента.

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

    М-м-м, не совсем верно переведен термин “The Purist”. Purist != Puritan.

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

    Если оставаться на уровне концепции, то сложно что-либо добавить или возразить. Да, должны быть и Роли и Персоны. Да, нужен баланс. Но, как только мы переходим к конкретным организациям и конкретным людям, вот тут и возникают нюансы. А это уже совсем другой разговор.

  • Пункт №1 какой-то странный. В каком месте какой книги сказано, что у всех пользователей должен быть одинаковый уровень обслуживания?

    Почему разные уровни сервиса в SLM для разных клиентов нас не смущают, а с появлением аббревиатуры VIP наступает коллапс по ресурсам?


Добавить комментарий для Олег СкрынникОтменить ответ

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

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM