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

SLA. Реинкарнация

happy-user-experience-designРедакция портала RealITSM всегда призывает ориентироваться на  интересы потребителей и заказчиков услуг, и сегодня мы возвращаемся к этой теме.

Основатель компании StackState, Марк Бэккер (Mark Bakker) в своей заметке о качестве услуг рассуждает об актуальности SLA, как инструмента взаимодействия бизнеса и поставщика информационных услуг.

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

Для того, чтобы заполнить этот пробел, нам предлагается измерять параметры пользовательского опыта (user eXperience) и включать их в соглашения (XLA), проведя при этом надлежащие корелляции с существующими техническими параметрами.

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

Чем отличаются SLA от XLA:

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

Нужно ли в таком ключе прекратить практику измерения параметров SLA? Конечно нет! Объединение пулов этих параметров позволяет проводить более качественный анализ и принимать более точные решения по изменению и развитию услуги.

Что же предлагается измерять и оценивать?

  • Бизнес влияние: оптимизация бизнес-результатов, основанных на услугах, предоставляемых ИТ службой, основываясь на данных о пользовательских транзакциях;
  • Производительность: мониторинг и оптимизация эффективности предоставления услуги конечным потребителям, измеряя производительность бизнес-операций;
  • Потребление услуги: описание частоты запросов услуги, профилей потребления;
  • Продуктивность пользователей: оптимизация взаимодействия с пользователем при предоставлении бизнес-услуги;
  • Дизайн и архитектура: оптимизация доступа пользователей к контенту в части навигации по нему, а также релевантности контента.

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

Мнение редакции:

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

Основных сложностей при организации оценки пользовательского опыта несколько:

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

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

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

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

 

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

Есть ли у вас средства бизнес-мониторинга, удается ли вам получать нужные вам параметры для оценки?

Как вам идея выделения отдельных документов – XLA?

 

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

  • Альберт

    Неплохая система бизнес-мониторинга описана в Матрице, но нужна ли нам она? Мы живые люди каждый имеет право на свой индивидуальный user eXperience который может и должен меняться.

    • Лично мне идея очень импонирует. Часто сталкиваюсь с функционально прекрасными вещами, инструментами, которыми при всем желании неудобно пользоваться. Для ряда продуктов и услуг (в силу значительного конкурентного давления) характеристики обеспечивающие пользовательский опыт становятся чрезвычайно неотъемлимым и важным их качеством. Для цифровых услуг, с учетом колоссальной скорости их изменения, даже присутствует соблазн причислять их к warranty, а не к utility в ряде случаев.

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

  • Моя идея (в контексте девяти принципов), гораздо проще: не надо вообще заниматься SLA, пока это возможно. Каталог – да. Бизнес-ориентированная отчетность – да. Регулярный контакт – да. SIP – да 2 раза. SLA – только когда все перечисленное уже есть и работает.

    • Андрей

      Я не понял противопоставления SLA, каталога и бизнесориентированной отчетности. SLA это и есть бизнес ориентированная отчетность, которую невозмоно сформировать без каталога ИТ услуг.

  • Андрей

    В принципе речь идет о уже давно решаемой проблеме. Качество услуг, это , извините за тафтологию, качественный параметр. Для любого качественного парметра есть проблема его формирования через количественные показатели. Хорошо – это сколько в Гигабайтах, герцах и т.д.? Поскольку первые средства ИТ мониторинга ориентировались на контроль технологических параметров – загруженность сетевых портов, процессоров, памяти и т.д. Всегда была очень серьёзная проблема, даже при наличии ресурсно-сервисной модели, свести эти показатели к общей оценке качества. Поскольку из всех характеристик качества информации в Operations формирутеся только доступность/актуальность, то и решили помимо мониторинга технологических параметров отслеживать и такой параметр, как время отклика приложения. Инструменты первых поколений либо внедрялись в код, либо использовали тестовые посылки. Это во-первых не совсем точно отражает реальное положение вещей, поскольку посылки тестовые, а не реальные транзакции, во-вторых это не везде применимо, поскольку эти посылки вносят искажения в объект мониторинга. Современные средства APM(Application Performance Management ) уже используют другие методы – прослушивание трафика через служебный порт, вычленения из него реальных транзакций и оценка времени отклика реальных транзакций без внесения каких либо искажений в объект наблюдения. И вот эту, напрямую получаемую метрику, уже можно использовать в SLA как характеристику качества ИТ услуги. Эти же средства позволяют решать и другие перечисленные задачи – анализ реальных пользовательских транзакций (частота, поторяемость и т.д.). В принципе этот класс систем так и называют – user experience.

  • Владимир

    По мне, так user experience – это оценка решения каждого обращения со стороны закзчика. Конечно, во многом эти оценки носят эмоциональный характер (иногда, ИТ не виноват) – но это правильно: раз Кдиент оказался в такой ситуации, значит всё равно – косяк Исполнителя (нужно было облизать и/или донести сложившуюся ситуацию до заказчика).


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

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

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM