Как-то раз мне понадобилось написать положение о качестве услуг. С одной стороны, я немного слышал про ITIL и уже написал несколько регламентов, а с другой — у меня никак не складывалась картина “как это должно работать”. Мне нужна была практичная модель, а не набор пространных тезисов.
Наличие такой модели автоматически не гарантирует высокое качество продукта или услуги. Она лишь показывает, что в компании понимают как с этим работать, а высокое качество не всегда достигается большими затратами. Чаще оно основано на дисциплине, системном подходе и учёте обратной связи от пользователей. Прелесть этой модели также в том, что она универсальна и может применяться не только в ИТ.
Описание модели
А в чем проблема-то? Берешь название этой статьи, вставляешь в поисковик и выбираешь. Увы, но я не нашел ничего подходящего, а общение с ИИ только еще больше запутывало концепцию. Была бы за окном зима, я бы пошел чистить снег (говорят, помогает)…
Написание любого ЛНА (локального нормативного акта) начинается с предметной области. Отправной точкой стало определение услуги, как результата совместной деятельности Поставщика и Потребителя (участников взаимодействия). Но ведь ровно такой же подход можно использовать для определения качества — это тоже результат, который не может быть достигнут в одностороннем порядке. Оставалось только наделить это взаимодействие нужными атрибутами. Так появилась схема:
Не имеет значения, кто из участников начнет взаимодействие первым, но чтобы оно состоялось, услуга должна быть спроектирована. Поскольку с точки зрения ITIL именно Поставщик играет ведущую роль в предоставлении услуг (помогая Потребителю выполнить свою часть обязательств), то он и планирует предоставление услуги исходя из своих возможностей и понимания рынка:
-
определяет метрики ее производительности и эффективности (SLI, Service Level Indicator);
-
для каждой SLI определяет её предельные значения, которые он способен достигнуть (SLO, Service Level Objective — т.н. “право на ошибку”) чтобы не превысить заявленные значения в SLA;
-
составляет и согласует с Потребителем гарантированный уровень обслуживания (SLA, Service Level Agreement) на основе предоставленных Потребителем требований (SLR, Service level requirement).
Далее наступает этап предоставления услуги с оценкой фактических показаний SLI. Раз в какой-то промежуток времени проводится анализ обратной связи и соблюдения SLA, потом принимаются корректирующие меры, если необходимо. Старый добрый PDCA.
Примечание 1. Потребности и требования — понятия разные. Рядовой пользователь может и не знать чего хотеть. Как правило, у него есть потребность в “плавности прокрутки текста”, а “экран с частотой обновления 120 Гц” ему неинтересен (ну ок, сейчас это устоявшееся понятие и его знают все, я образно). Для этого в ITIL придумали 3 роли на стороне Потребителя — Пользователь, Заказчик и Спонсор. Так вот задача Пользователя — суметь воспользоваться предоставляемой услугой и с удовольствием выполнить свою работу. Конкретные требования составляет Заказчик, а Спонсор все это оплачивает.
Примечание 2. Когда начинать писать положение о качестве? Продукт или услуга не появляются из воздуха, компания же ведет какую-то деятельность в этом направлении. Поэтому начинать надо примерно тогда, когда описаны её основные бизнес-процессы. Если приступить раньше этого момента, то еще не сформирована предметная область, нет понимания объектов управления и метрик для оценки этих процессов. Если позже, то возможен большой объем по корректировке существующих ЛНА, чтобы привести их к единому формату (либо смириться, что “так исторически сложилось”).
Особенности модели
Эта модель не затрагивает финансовые аспекты, поэтому поясню 2 момента:
-
Безусловно, стоимость оборудования и образования сотрудников играет важную роль. Однако, как я написал в самом начале статьи, эта зависимость не всегда прямая. Качество текста никак не станет лучше, если поменять клавиатуру за 1000р на “механику” за 10000р (хотя легенда и гласит, что айтишник способен продержаться неделю на крошках из-под клавиш, но едва ли такой подход можно назвать вдохновляющим). Не всем также нужен автомобиль, способный проехать гонку Need for Speed: The Run.
-
“Как оплачено, так и нафигачено”. Это не должно быть нормой. Финансовые трудности участников взаимодействия — это лишь повод для пересмотра договорных отношений, но не изменения уровня качества в одностороннем порядке.
Полезные ссылки:
Критерии оценки качества
Получается, что качество – это не свойство продукта или услуги, а степень соответствия их характеристик у Поставщика ожиданиям и требованиям у Потребителя.
Уровень качества определяется на основе двух типов показателей:
-
Объективные (количественные) – достижение целевых метрик бизнес-процессов и показателей SLA. Их оценка производится на основе статистики в системах мониторинга и управления заявками;
-
Субъективные (качественные) – общее восприятие услуги, удовлетворённость пользователей качеством обслуживания, вежливость работников, характер коммуникации в командах и т.п. Метод оценки – обработка информации по обратной связи от пользователей, плановые проверки, анализ телефонных разговоров, переписки и т.п.
Таким образом качество не подлежит однозначной оценке как «Хорошее» или «Плохое». Корректный вывод об уровне качества должен позволить понять, что именно нужно улучшать и почему, например: «Услуга не соответствует пункту 3.1 SLA на 35%, средняя оценка удовлетворенности Пользователей равна 4,2». Эта оценка может означать, что услуга не пользуется спросом, либо система мониторинга настроена некорректно.
Начинаем оценивать, что с процессами? Как компания выполняет свою работу по созданию продукта или услуги — как единый механизм или “кто во что горазд”?
Из миниатюры Аркадия Райкина “Сервис”:
Я прихожу к директору:
— Слушай, кто сшил костюм? Кто это сделал? Я не буду драться, не буду кричать, я только хочу в глаза ему посмотреть.
Выходит сто человек. Я говорю:
— Ребята, кто сшил костюм?
Они говорят:
— Мы!
Я говорю:
— Кто это «мы»?
Они говорят:
— У нас узкая специализация. Один пришивает карман, один — проймочку, я лично пришиваю пуговицы. К пуговицам претензии есть?
— Нет! Пришиты насмерть, не оторвёшь! Кто сшил костюм? Кто вместо штанов мне рукава пришил? Кто вместо рукавов мне штаны пришпандорил? Кто это сделал?!
Они говорят:
— Вы скажите спасибо, что мы к гульфику рукав не пришили.
Представляете? Их – сто, а я – один. И все стоят, как пуговицы: насмерть. И я сказал:
— Привет, ребята! Вы хорошо устроились!
Требования к процессам
-
все существующие в компании процессы должны быть зафиксированы в соответствующих ЛНА (регламенты, инструкции, стандарты и т.п.);
-
к этим ЛНА должны быть определены требования по формату, структуре и содержанию, а также способам согласования, регистрации и ведения;
-
положения процессов в действующих ЛНА не должны противоречить друг другу, по неактуальным ЛНА должна выполняться корректировка;
-
требования по согласованности: единство подхода в отношении правил оценки услуг, терминологии, единиц измерения и формул расчета метрик, каналов коммуникации, источников данных для формированию отчетности, используемым нотациям и т.п.
Метрики
А что там по метрикам? Ну, их довольно много, не вижу смысла перечислять, но ограничусь категориями (в зависимости от целей процесса и управленческого учета):
-
Показатели производительности – показывают общий объем работ и затраченные ресурсы (пример: «Количество зарегистрированных заявок», «Трудозатраты исполнителей на решение заявки»);
-
Показатели эффективности – показывают оптимальность использования ресурсов (время, персонал, технологии) для достижения результата (пример: «Среднее время решения заявки»);
-
Показатели результативности (это можно отнести к показателям качества) – показывают степень достижения целей процесса (пример: «Процент успешно реализованных изменений»);
-
Показатели качества – показывают степень соответствия выполнения процесса установленным стандартам, регламентам или ожиданиям пользователей (пример: SLA, соблюдение деловой этики и т.п.);
-
Показатели дефекта (показатели, обратные качественным) – показывают количество ошибок, сбоев или отклонений от требуемых стандартов на выходе процесса (пример: «Доля заявок, возвращённых на доработку»);
-
Целевой показатель – конкретное плановое значение, установленное для любой из метрик процесса на определенный период времени (пример: «Средняя оценка удовлетворенности пользователей ≥ 4 из 5»).
Полезные ссылки:
Требования к SLA
-
в SLA должен содержаться перечень параметров услуги (их состав, время и условия предоставления, сроки реакции и т.п.), перечень услуг должен составляться на основе Каталога услуг;
-
параметры услуги должны поддерживаться в актуальном состоянии и быть зафиксированы в договорах между Поставщиком и Потребителем;
-
параметры услуги не должны превышать аналогичные параметры SLA во внешних соглашениях компании, на базе которых оказывается услуга.
Полезная статья: “Как написать хороший SLA”.
Для демонстрации достижений показателей SLA удобно использовать диаграмму SLAM (Service Level Agreement Monitoring chart). Она служит не только инструментом отчетности, но и помогает для оперативного управления качеством. На примере: доступность Услуги в SLA=90%, а SLO=95%
Управление коммуникациями
SLA выполнен и всё? Зачем нужна обратная связь?
Это не только количество звездочек по решенным задачам (которые пользователи вообще могут не ставить и как тогда оценивать?). Это и оповещения о событиях, влияющих на оказание услуг (профилактические мероприятия, выявленные баги и т.п.). И планирование, организация и документирование встреч участников взаимодействия (с инициативой от каждой стороны!) — форумы, выставки, вебинары и т.п. То есть всё, что так или иначе помогает в определении вектора развития.
Поддержка уровня качества
Меры и стратегии, направленные на достижение заданных стандартов качества:
-
Проектирование новых и изменение существующих услуг на всем их жизненном цикле с учетом функциональности, стоимости, метрик процессов, оценки полезности, эмоционального влияния на пользователей и т.п.;
-
Управление инцидентами, включая проактивное выявление рисков, угрожающих непрерывности, доступности или безопасности услуги, а также принятие мер по их предотвращению и своевременному информированию пользователей;
-
Тестирование услуги — регулярные проверки восстановления после сбоев, проверки безопасности, нагрузочное тестирование критичных сервисов;
-
Управление изменениями/конфигурациями — обеспечивает контроль над состоянием услуги, ее компонентов и связей между ними;
-
Аудит и оценка — регулярный мониторинг выполнения SLA, оценка зрелости процессов компании, аудит на соответствие отраслевым стандартам;
-
Обучение и развитие персонала — постоянное обучение сотрудников новым технологиям и навыкам коммуникации для повышения качества взаимодействия с пользователями;
-
Развитие базы знаний — для сокращения объема работ технической поддержки, времени на адаптацию новых сотрудников, решения инцидентов и т.п.;
-
Управление требованиями к услуге — регулярная работа с заказчиком по определению и пересмотру требований к услуге, фиксируемых в SLA;
-
Непрерывное улучшение услуг с помощью сбора и анализа обратной связи, целевых метрик процессов и внедрении необходимых изменений;
-
Автоматизация процессов управления для рутинных задач, формирования отчетности и оценки статистических данных;
-
Контроль качества внешних контрагентов, с помощью ресурсов которых оказывается услуга;
-
Использование лучших практик для повышения эффективности процессов управления.
Пересмотр критериев качества
Критерии качества не являются неизменными во времени. Их пересмотр следует выполнять как на регулярной основе, так и при наступлении событий, влияющих на бизнес Поставщика или Потребителя.
События, инициируемые Поставщиком или Потребителем:
-
регулярное несоответствие услуги ожиданиям Потребителя: постоянные жалобы пользователей при формальном соблюдении SLA;
-
изменение бизнес-процессов: реорганизация, запуск нового продукта или услуги, выход на новые рынки, слияния, поглощения и т.п.;
-
изменение стратегических целей или приоритетов бизнеса: смена фокуса с роста на сокращение расходов, либо повышение важности клиентского опыта;
-
существенное изменение объемов потребления услуги: резкий рост (или падение) количества пользователей, их обращений или обрабатываемых данных;
-
появление новых требований регуляторов или стандартов: изменение законодательства (например, в области защиты персональных данных), требующее изменения в уровне безопасности или доступности услуг;
События, инициируемые Поставщиком:
-
крупные инциденты и проблемы: системная слабость или несовершенство действующих критериев;
-
значимые изменения в ИТ-инфраструктуре: миграция в облако (смена облачного провайдера), модернизация или замена ключевого программного обеспечения, внедрение новых технологий;
-
существенные изменения стоимости компонентов услуги (подорожание лицензий, оборудования и т.п.);
-
смена финансовой модели функционирования ИТ-подразделений;
-
запрос Потребителя на повышение уровня качества услуг;
-
результаты внутреннего аудита или оценки зрелости процессов компании;
Внешние события (рынок и окружение):
-
изменение конкурентной среды;
-
появление новых технологических трендов;
-
глобальные киберугрозы или инциденты в отрасли, требующие пересмотра критериев в области безопасности и устойчивости.
По итогам пересмотра могут корректироваться:
-
ценовая политика компании;
-
состав услуг в Каталоге услуг;
-
параметры предоставления услуги в SLA;
-
организационная структура компании;
-
положения существующих ЛНА.
Про регламенты
Коль скоро я затронул тему ЛНА — это тоже заинтересованность двух сторон. И сотрудника, чтобы не угадывать как ему работать (включая руководителей — “а все ли процессы своего подразделения я знаю?”). И работодателя — для уверенности, что “все идет по плану”. Но просто написать регламент недостаточно. Кто-то должен уметь принимать решения и претворять их в жизнь, а чтобы регламенты читали, нужно соблюсти “всего лишь” 3 условия:
-
Регламент не должен быть большим. Вспомните компьютерные или настольные игры, что интереснее: часами изучать туториал или играть?
-
Регламентов не должно быть слишком много. Чем больше информации, тем меньше желания ее читать. Если в компании 100500 ЛНА, то их нужно систематизировать, проводить обучение, семинары и т.п. Люди не роботы, на них недостаточно “вывалить” всю эту пачку и ожидать моментального прозрения.
-
Регламент должен быть читабельным. Здесь отмечу труды Максима Ильяхова, невероятную пользу от форматирования текста и добавлю про схемы. Безусловно, они нужны, но не стоит их делать на каждый шаг — вы же сами потом запутаетесь что чему соответствует.
Бюрократия — полезная штука, но как найти баланс между тем, где “инициатива наказуема” и когда нужно включать голову, характер и обаяние?
ссылка на оригинал статьи https://habr.com/ru/articles/1044662/