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

Недоступная доступность

На прошлой неделе, во время курса «Основы ITIL V3», мы разговорились со слушателями про доступность ИТ-услуг.

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

Ответ коллег был следующим.

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

У меня было другое мнение:

Конечно же в конечной ценности услуг присутствует удовлетворенность заказчиков и пользователей. Конечно, эту ценность создает поставщик услуг. Конечно поставщик услуг должен делать услугу понятной и удобной для тех, кто ею пользуется. Если он этого не делает, то услуга недоступна. Следовательно, поставщик услуг обязан обучать пользователей правильному потреблению услуги. Как пример: представьте себе, насколько довольны вы будете гостиницей (поставщиком услуг), если не сможете найти ее по адресу, или, например, вы не знаете, как включить свет в номере?

Шуточный вопрос к читателям: «Кто прав?» =)

Серьезно – как лучше всего аргументировать ту или другую позицию?

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

  • Ответ на шуточный вопрос, как и на все прочие вопросы управления ИТ-услугами (мне все чаще так кажется), можно найти в вебинаре Дмитрия – том, который якобы про управление изменениями и релизами, а на самом деле про всё (http://www.cleverics.ru/ru/subject-field/webinars/380-webinar-6-2012-di). Слайды №№ 7 и 8.

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

    Отсюда и аргументы, я думаю. Это еще один частный вопрос о границах ответственности.

    • “Если услуги состоят в технологическом обеспечении бизнес-процессов, то вторая точка зрения более уместна.”

      Как ни приятно, что тебя цитируют, но в данном случае не соглашусь. Если незнание пользователя трактовать, как инцидент, то будет совсем туго в проведении границы между инцидентами и сервисными запросами. Я полагаю так: если отказ на стороне поставщика (предоставления услуги), это инцидент, иначе – сервисный запрос (например, консультация).

      Что касается доступности, тут всё глубже – зависит, для чего считаем доступность. Если наша задача оценить качество предоставления услуг (например, для премирования / наказания руководителей ДИТ), то вряд ли расчёт доступности имеет смысл базировать на одиночных инцидентах – крайне неудобно считать, да и картина не показательна. Потребуется вводить понятие глобального отказа и обеспечить их учёт.

      Наконец, что касается разницы двух подходов в идентификации услуг, то они влияют на то, что считать доступностью. В первом случае (обеспечение работоспособности систем) – доступность системы. Во втором случае (технологическое обеспечение процесса) – возможность выполнения операций данного процесса. В обоих случаях картина по доступности обычно сложнее, чем одно число. В самом деле, у системы обычно есть отдельные модули / подсистемы / функции, а у бизнес-процесса – VBF. Поэтому имеет смысл уходить от доступности услуги целиком к доступности того, что можно измерить – функций системы автоматизации или VBF. Если строить работу так, то и неоднозначности с инцидентами будет гораздо меньше.

      • Если рассуждать очень упрощенно, то неспособность пользователя пользоваться корректно предоставляемой услугой, скорее всего, является следствием одной из двух причин:
        1. пользователь неграмотен
        2. потребление требует специальных знаний или навыков, которые поставщик должен был передать пользователю, но не передал.

        Типичный пример для причины 1: пользователь – недееспособный двоечник, взятый на работу по знакомству;
        Типичный пример для причины 2: поставщик развернул новую систему, а обучение пользователей работе с ней запланировал на следующий квартал в связи с высокой загрузкой учебных классов.

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

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

        • “должен был передать пользователю, но не передал.”

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

          “Если я верно понял суть дискуссии на курсе, речь именно о том, что ответить конкретному пользователю — «у нас все работает, до свидания» или «ваша заявка принята, сейчас поможем».”

          Странно. А как это связано с доступностью? Если пользователь к нам обратился за помощью, мы ему помогаем. Даже если это он виноват, а не мы. Иначе говорить о сервисном подходе, да ещё в “столь высоком смысле” 🙂 по-моему не приходится.

          • Денисов Денис

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

            • Их возмущение может быть вполне оправданно, но не принять и не обслужить они не могут. Не должны мочь. Снимайте статистику, делайте выводы по уровню грамотности, предлагайте оргмеры, учите первую линию.
              Самая засада с грамотностью когда в компании большая текучка (розница, сетевые банки). Здесь, как мне кажется, надо поднимать вопрос о возложении хотя бы части ответственности на руководителей соответствующих офисов.
              И всё же доступность услуг здесь совсем ни при чём (если только мы не обсуждаем услугу обучения).

        • Роман, да нет, наверное действительно помогли бы, но хотели бы, чтобы такая помощь была разовая, и никак не сказывалась на их, ИТ-шных, премиях.
          Вопрос остается, если хотите, в другой формулировке:
          Если услуга массовая (как описывал Дмитрий ниже), то как распределять ответственность за обучение пользователей между ИТ-организацией и заказчиками? Или еще жестче: как убедить заказчика при запуске услуги потратиться на обучение пользователей?;)

    • Grigory Kornilov

      Под доступностью сервиса я бы подразумевал функционирование на договоренном уровне, ведь в итоге это KPI по SLA.

      В SLA – двусторонний документ, если там не описаны обязательства пользователей (в том числе и требуемый уровень его знаний), то однозначного ответа на вопрос не может быть.
      Цель сервиса не его красивое существование, а приносимое им value для бизнеса.

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

  • Вадим

    Ах! как хотелось бы объявить недоступной (в первую очередь – для понимания) какую-нибудь систему, с которой невозможно работать, в которой регулярно пропадают данные, поддержка которой оставляет желать лучшего.
    вообще я сторонник точки зрения, что “должно ИТ”, т.к. если оно этого не делает, то может оно и не нужно такое?
    но жизнь …э… несколько многообразнее.

  • Pavel Solopov

    Кто за что отвечает, вопрос договорённостей. Если говорить о сервисах, то в один сервис я бы смешивать это не стал. Даже если и отвечает за это ИТ, то работающая система это один сервис, а научить пользователя ей пользоваться это другой. Поскольку тут, банально, разные базы формирования стоимости этих услуг.


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

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

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM