Свяжитесь с нами
Продукт
Возможности
Мероприятия
Материалы
Крупные предприятия
Свяжитесь с нами

Качество сервиса Service Quality

На какой вопрос отвечает «Какая конфигурация нефункциональных атрибутов назначена сервису или контракту?»

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

Аналогия Как готовый набор характеристик, который приписывается к услуге или договору.

Разобраться

Зачем это нужно

Определяет набор нефункциональных требований, привязанных к сервису или контракту.

Применить

Когда это нужно, а когда нет

Когда нужно

  • Описываются требования к качеству работы сервиса
  • Формируется контракт на обслуживание или разработку
  • Назначаются атрибуты качества бизнес- или технологическому сервису

Когда не нужно

Типичные ошибки

  • 01Смешивают требования к возможностям системы с качеством сервиса, хотя это разные категории.
  • 02Применяют понятие только к технологическому уровню, забывая, что оно валидно и для бизнес-сервисов.
  • 03Считают это разовым параметром, тогда как это конфигурация, которая может быть предзадана и назначена контракту.

Сверить с первоисточниками

Что говорят стандарты

Определения из источников с переводом и ссылкой на раздел. Категория показывает назначение каждого подхода.

A configuration of non-functional requirements or attributes that may be assigned to a business, application, or technology service.

Раздел стандартаСтрока реестра

Ещё 1 редакция этого подхода
A preset configuration of non-functional attributes that may be assigned to a service or service contract.

Перевод Архитектурная сущность TOGAF: качество сервиса.

TOGAF Standard, Version 9.2, The Open Group, 2018, C182; гл. 30 «Content Metamodel», §30.5 «Content Metamodel Entities», табл. «Metamodel Entity | Description»

С чем связано

Связи понятия и его место в структуре подхода.

TOGAF

Architecture Definition: Business Architecture / Определение архитектуры: бизнес-архитектура

  • СоответствуетContract
  • Применяется кContract
  • Применяется кService

Как измерить

Доступность критичных бизнес-систем%

Доля времени, в течение которого критичные для бизнеса системы доступны. KPI ценностного потока Detect to Correct; сам стандарт оговаривает, что управление доступностью в этом потоке ещё не представлено и будет рассмотрено в будущих редакциях (разд. 8.4.9).

Доступность = время работоспособного состояния / общее время наблюдения
  • время работоспособного состояния время, когда система выполняла свои функции
  • общее время наблюдения весь период, за который считается доступность
Число нарушенных соглашений об уровне сервисашт.

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

Число нарушенных соглашений = количество SLA и OLA, по которым за период нарушены согласованные условия
  • SLA соглашение об уровне сервиса с потребителем
  • OLA операционное соглашение внутри поставщика сервиса

Сущность прямо посвящена качеству сервиса; доступность и число нарушенных соглашений — два показателя IT4IT, которыми это качество и меряют.

14 дней бесплатно

Опишите архитектуру своей компании в Storm

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

Попробовать бесплатно Без банковской карты

Это же в StormАрхитектура систем и интеграцийРеестр процессовКарта бизнес-способностей

Поддержка