Сервисная модель — полный рабочий контур

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

Что это даёт в реальной работе

Единый язык для продукта, операций, IT, QA, поддержки, рисков, ИБ и юридической функции.
Понимание, где сервис реально исполняется: в канале, CRM, workflow, системе обращений, интеграциях, ручных операциях и базе знаний.
Возможность отличить дизайн клиентского опыта от операционной способности этот опыт доставить.
Управляемый переход от as-is к target-state.
Основание для incident-review и change requests после запуска.

Рабочие слои

Слой	Что фиксирует	Связанные заметки
Клиентский опыт	шаги клиента, ожидания, статусы, боли	SJM и CJM — различия
Процесс	этапы, роли, handoffs, исключения	Моделирование процессов и сервисов
Архитектура	системы, интеграции, data ownership, качества	Архитектура и интеграция сервисов
Инструменты исполнения	CRM, workflow, система обращений, база знаний	Поддержка сопровождение и инструменты сервиса
Качество	UAT, regression, defect management, QA ответов	Тестирование и качество сервисов
Управление	владельцы, SLA, changelog, lifecycle	SJM — governance и lifecycle карты
Риски	customer harm, compliance, operational risk	Управление рисками сервисных изменений

Локальный корпус знаний

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

Источник корпуса	Как использовать в контуре сервиса
SJM Source - Rex Black ISTQB CTFL 2020	test process, defect management, risk-based testing, test tools, regression
SJM Source - Канер Фолк Нгуен 2001	test strategy, oracle problem, coverage, defect reporting, limits of complete testing
SJM Source - Myers Art of Software Testing 2011	test-case design, негативное мышление тестировщика, inspections, regression
SJM Source - Куликов Базовый курс 2023	русскоязычная практическая база: требования, чек-листы, тест-кейсы, дефекты, RCA, автоматизация
SJM Source - Desfray TOGAF UML BPMN 2014	TOGAF/UML/BPMN, viewpoints, traceability между процессом, системой и архитектурой
SJM Source - Richards Ford Software Architecture 2025	architecture characteristics, trade-offs, fitness functions, ADR, architecture risk

Практический смысл корпуса: каждый артефакт сервисной модели должен иметь проверяемый след. SJM-шаг связывается с процессом, состоянием, архитектурным решением, test oracle, мониторингом, KB и change request.

Петля проверяемости сервиса

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

flowchart LR
    A[Требование или SJM шаг] --> B[Тест-анализ]
    B --> C[Критерий приёмки и oracle]
    C --> D[Чек-лист / тест-кейс]
    D --> E[Evidence]
    E --> F{Готово?}
    F -->|Да| G[Regression / monitoring]
    F -->|Нет| H[Defect report]
    H --> I[RCA / triage]
    I --> J[Change request]
    J --> A

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

Как применять в сервисной модели

Начинать не с схемы, а с назначения сервиса: кому он нужен, какой результат обещает, какая ошибка будет вредной.
Описывать сервис в двух состояниях: as-is и target-state.
Разделять клиентский статус и внутренний статус обработки.
Проверять, какой инструмент является источником истины для каждого статуса.
Фиксировать владельца каждого этапа, системы и handoff.
Добавлять evidence: обращения, логи, SLA, дефекты, инциденты, жалобы, аналитика.
Закрывать цикл изменением: что именно меняется в процессе, системе, базе знаний, мониторинге или роли.

Связь с SJM

SJM — это карта доставки сервиса. Она показывает, как клиентский путь собирается из frontstage, backstage, support processes, systems, metrics и controls.

Полный контур сервисной модели добавляет к SJM:

business context: зачем сервис существует;
requirements context: какие требования должны быть выполнены;
architecture context: какие системы и качества ограничивают решение;
tooling context: где сервис исполняется и сопровождается;
support context: как сервис живёт после запуска;
change context: как карта меняется после evidence.

Связь с инструментами поддержки и сопровождения

Сервисная модель должна отвечать на вопросы:

где клиент создаёт обращение;
где фиксируется статус;
где поддержка видит историю клиента;
какая база знаний используется первой линией;
какие события пишутся в логи;
где настроен мониторинг;
как контролируется SLA;
кто создаёт change request после повторяющейся проблемы.

Если на эти вопросы нет ответа, карта остаётся полезной для обсуждения, но слабой для сопровождения.

Практический чек-лист

Ограничения

Сервисная модель не должна превращаться в тяжёлую CMS.
Не нужно документировать каждую микрокнопку, если она не влияет на доставку сервиса.
Непроверенные регуляторные, архитектурные и операционные утверждения помечать source_required.