# ВКУС: C4 Context, клиентский flow и связь с capabilities

Версия: `v0.1`  
Назначение: companion-документ к PDF `ВКУС_C4_context_flow_capabilities_v0.1.pdf` для самостоятельного изучения командой.

Документ показывает, как связать:

```text
клиентский путь
→ capabilities
→ архитектурные компоненты
→ метрики
```

Ключевая идея: диаграммы не должны быть «красивой картинкой отдельно от требований». Они должны помогать проследить, **какая capability нужна на каком шаге клиентского пути и какими архитектурными элементами она реализуется**.

---

## 1. Общая логика комплекта диаграмм

Для обсуждения целевой витрины сервисного входа лучше использовать не одну перегруженную схему, а набор связанных представлений:

| Артефакт | Что показывает | Зачем нужен |
|---|---|---|
| C4 Context Diagram | Границы целевой системы, акторов и внешние системы | Понять архитектурный контекст решения |
| Customer Journey Flow | Путь пользователя и включение capabilities | Понять, как меняется клиентский опыт |
| Service Blueprint Light | Пользователь / Frontstage / Backstage / Системы | Связать UX, capabilities и архитектуру |
| Traceability Matrix | Шаг CJM → capability → компонент → метрика | Сделать связь формальной и проверяемой |

### Не так

```text
Одна супер-диаграмма со всеми системами, шагами, capabilities, roadmap и стрелками.
```

### А вот так

```text
1. Context — кто и с какими системами взаимодействует.
2. Flow — как пользователь проходит путь.
3. Blueprint — какие capabilities и системы включаются на каждом шаге.
4. Matrix — формальная трассировка CJM → capabilities → architecture.
```

---

## 2. Capability-легенда

Чтобы диаграммы можно было читать и сопоставлять между собой, вводятся постоянные ID capabilities.

| ID | Capability | Краткий смысл |
|---|---|---|
| CAP-01 | Единый сервисный вход | Пользователь идет в один понятный вход во ВКУС |
| CAP-02 | Понимание намерения пользователя | Система понимает задачу в пользовательском языке |
| CAP-03 | Помощь до создания обращения | Витрина пытается помочь до создания заявки |
| CAP-04 | Предзаполнение обращения | Система подставляет известные данные и контекст |
| CAP-05 | Автомаршрутизация и корректное создание обращения | Обращение уходит в правильный процесс / группу |
| CAP-06 | Прозрачный статус обращения | Пользователь понимает, что происходит |
| CAP-07 | Уведомления и управление ожиданиями | Пользователь видит next best action и не пропускает уточнения |
| CAP-08 | Аналитика клиентского пути | События, тексты и логи превращаются в метрики |
| CAP-09 | Управление знаниями и инструкциями | Инструкции актуальны, понятны и используются в self-service |
| CAP-10 | Контур постоянного улучшения | Обратная связь попадает в backlog улучшений |

---

## 3. C4 Context Diagram v0.1

### 3.1. Назначение

C4 Context Diagram отвечает на вопрос:

> Какие люди и внешние системы взаимодействуют с целевой системой «Витрина сервисного входа ВКУС»?

На этом уровне не детализируем внутренние микросервисы. Показываем границу целевой системы и внешние зависимости.

### 3.2. Mermaid-код

```mermaid
flowchart LR

    %% Actors
    User["Сотрудник компании<br/>пользователь поддержки"]
    Support["Сотрудник техподдержки"]
    KnowledgeOwner["Владелец знаний / инструкций"]
    ServiceOwner["Владелец сервиса / аналитик CX"]

    %% Target system
    subgraph Target["Целевая система: Витрина сервисного входа ВКУС"]
        VKUS["ВКУС<br/>единый сервисный вход<br/>CAP-01"]
    end

    %% External systems
    ITSM["ITSM / Creatio BPM<br/>обращения, SLA, статусы<br/>CAP-05 CAP-06"]
    ServiceCatalog["Каталог услуг<br/>услуги, карточки, маршруты<br/>CAP-02 CAP-05"]
    KnowledgeBase["База знаний / инструкции<br/>Confluence, SharePoint, файлы<br/>CAP-03 CAP-09"]
    SearchRAG["Search / RAG / LLM layer<br/>поиск, классификация, ответы<br/>CAP-02 CAP-03"]
    IAM["IAM / AD<br/>пользователь, роли, доступы<br/>CAP-04"]
    HR["HR / оргструктура<br/>подразделение, руководитель<br/>CAP-04"]
    CMDB["CMDB / Inventory<br/>системы, сервисы, зависимости<br/>CAP-04 CAP-05"]
    Notify["Каналы уведомлений<br/>почта, Teams, push<br/>CAP-07"]
    Analytics["CX Analytics / Data Mart / BI<br/>метрики, тексты, логи<br/>CAP-08 CAP-10"]

    %% User interactions
    User -->|"Описывает задачу,<br/>получает ответ / заявку / статус"| VKUS
    VKUS -->|"Показывает статус,<br/>запрашивает уточнения"| User

    %% Support and owners
    Support -->|"Исполняет обращения"| ITSM
    KnowledgeOwner -->|"Актуализирует инструкции"| KnowledgeBase
    ServiceOwner -->|"Анализирует путь,<br/>формирует backlog улучшений"| Analytics

    %% System interactions
    VKUS <-->|"Создание обращения,<br/>комментарии, статусы"| ITSM
    VKUS <-->|"Поиск услуги,<br/>карточки, маршруты"| ServiceCatalog
    VKUS <-->|"Поиск ответа,<br/>источники знаний"| KnowledgeBase
    VKUS <-->|"Классификация намерения,<br/>поиск, краткий ответ"| SearchRAG
    VKUS <-->|"Данные пользователя,<br/>роли, доступы"| IAM
    VKUS <-->|"Оргданные"| HR
    VKUS <-->|"Контекст систем и сервисов"| CMDB
    VKUS -->|"Уведомления,<br/>next best action"| Notify
    VKUS -->|"События клиентского пути,<br/>логи, оценки"| Analytics

    ITSM -->|"Статусы, сроки,<br/>маршрутизация"| Analytics
    KnowledgeBase -->|"Качество знаний,<br/>knowledge gaps"| Analytics
    ServiceCatalog -->|"Проблемные карточки,<br/>ошибки выбора"| Analytics
```

### 3.3. Как читать диаграмму

**ВКУС** — это не просто портал и не отдельный экран. В этой модели он выступает как **граница целевой системы**: витрина сервисного входа.

**Search / RAG / LLM layer** — не центр архитектуры, а один из supporting layers, который помогает реализовать CAP-02 и CAP-03.

**Analytics / Data Mart / BI** — обязательная часть контекста, потому что без нее невозможны MVP 0 / Data Discovery, метрики и контур улучшений.

### 3.4. Вопросы для уточнения границ

| Вопрос | Почему важен |
|---|---|
| ВКУС — это вся целевая система или только frontstage? | Определяет границу C4 Context |
| Search/RAG/LLM layer — внутренний компонент или внешний сервис? | Влияет на следующий C4 Container уровень |
| Каталог услуг — часть решения или внешняя мастер-система? | Влияет на ответственность и governance |
| Analytics/Data Mart — отдельный компонент проекта или корпоративная платформа? | Влияет на архитектуру MVP 0 |
| Notification service — существующие каналы или новый компонент? | Влияет на MVP 4 |

---

## 4. Customer Journey Flow + Capabilities v0.1

### 4.1. Назначение

Диаграмма отвечает на вопрос:

> Как пользователь проходит путь, какие capabilities включаются на каждом шаге и какие архитектурные слои участвуют?

### 4.2. Mermaid-код

```mermaid
flowchart TB

    %% Journey steps
    S1["1. Возникла проблема<br/>Пользователь не может выполнить работу"]
    S2["2. Вход во ВКУС<br/>CAP-01"]
    S3["3. Описание задачи<br/>своими словами<br/>CAP-02"]
    S4{"4. Можно помочь<br/>без обращения?<br/>CAP-03 CAP-09"}
    S5["5A. Быстрый ответ /<br/>инструкция / next best action<br/>CAP-03 CAP-09"]
    S6{"Ответ помог?"}
    S7["5B. Создание обращения<br/>с контекстом<br/>CAP-04 CAP-05"]
    S8["6. Исполнение в ITSM<br/>маршрутизация, SLA<br/>CAP-05"]
    S9["7. Понятный статус<br/>и уведомления<br/>CAP-06 CAP-07"]
    S10["8. Получение результата<br/>что сделано / что проверить"]
    S11["9. Оценка результата<br/>CAP-08 CAP-10"]
    S12["10. Контур улучшения<br/>карточки, знания, маршрутизация<br/>CAP-08 CAP-09 CAP-10"]

    %% Main flow
    S1 --> S2 --> S3 --> S4
    S4 -->|Да| S5 --> S6
    S6 -->|Да| S11
    S6 -->|Нет| S7
    S4 -->|Нет| S7
    S7 --> S8 --> S9 --> S10 --> S11 --> S12

    %% Architecture side notes
    A1["ВКУС Frontstage<br/>задачная главная, поиск, карточка"]
    A2["Scenario & Intent Layer<br/>классификация, сценарии, уточнения"]
    A3["Knowledge Layer<br/>база знаний, RAG/search, источники"]
    A4["Form & Prefill Layer<br/>предзаполнение, валидация, context package"]
    A5["ITSM Execution Layer<br/>Creatio, маршрутизация, SLA"]
    A6["Status & Notification Layer<br/>статусы, уведомления, next best action"]
    A7["Analytics & Improvement Layer<br/>логи, тексты, BI, backlog"]

    S2 -.-> A1
    S3 -.-> A2
    S4 -.-> A2
    S5 -.-> A3
    S7 -.-> A4
    S8 -.-> A5
    S9 -.-> A6
    S11 -.-> A7
    S12 -.-> A7
```

### 4.3. Ключевой сдвиг

#### Не так

```text
Пользователь → форма → заявка → ожидание
```

#### А вот так

```text
Пользователь → описание задачи → быстрый ответ или предзаполненная заявка → понятный статус → оценка → улучшение сервиса
```

Важный принцип: обращение создается **не всегда**. Сначала витрина пытается помочь без создания заявки.

---

## 5. Service Blueprint Light v0.1

### 5.1. Назначение

Blueprint-вариант лучше всего показывает связь:

```text
путь пользователя
→ frontstage ВКУС
→ backstage capabilities
→ системы
```

Он полезен для совместного обсуждения UX, бизнес-аналитиками и архитекторами.

### 5.2. Mermaid-код

```mermaid
flowchart LR

    subgraph U["Пользователь"]
        U1["Возникла проблема"]
        U2["Открывает ВКУС"]
        U3["Описывает задачу"]
        U4["Получает ответ<br/>или создает обращение"]
        U5["Следит за статусом"]
        U6["Получает результат"]
        U7["Оценивает"]
    end

    subgraph F["Frontstage: ВКУС"]
        F1["Задачная главная<br/>CAP-01"]
        F2["Поле описания / сценарии<br/>CAP-02"]
        F3["Короткий ответ<br/>или карточка обращения<br/>CAP-03 CAP-04"]
        F4["Статус и next best action<br/>CAP-06 CAP-07"]
        F5["Оценка результата<br/>CAP-08 CAP-10"]
    end

    subgraph B["Backstage capabilities"]
        B1["Понимание намерения<br/>CAP-02"]
        B2["Поиск знаний<br/>CAP-03 CAP-09"]
        B3["Предзаполнение<br/>CAP-04"]
        B4["Маршрутизация<br/>CAP-05"]
        B5["Аналитика пути<br/>CAP-08"]
        B6["Feedback loop<br/>CAP-10"]
    end

    subgraph S["Системы"]
        S1["Каталог услуг"]
        S2["База знаний"]
        S3["Search / RAG / LLM"]
        S4["IAM / HR / CMDB"]
        S5["ITSM / Creatio"]
        S6["Notifications"]
        S7["Data Mart / BI"]
    end

    U1 --> U2 --> U3 --> U4 --> U5 --> U6 --> U7

    U2 --> F1
    U3 --> F2
    U4 --> F3
    U5 --> F4
    U7 --> F5

    F2 --> B1
    F3 --> B2
    F3 --> B3
    F3 --> B4
    F4 --> B4
    F5 --> B5
    B5 --> B6

    B1 --> S1
    B1 --> S3
    B2 --> S2
    B2 --> S3
    B3 --> S4
    B4 --> S5
    F4 --> S5
    F4 --> S6
    B5 --> S7
    B6 --> S2
    B6 --> S1
```

### 5.3. Как читать blueprint

| Дорожка | Что показывает |
|---|---|
| Пользователь | Линейный путь пользователя от проблемы до оценки результата |
| Frontstage: ВКУС | Что пользователь видит в витрине |
| Backstage capabilities | Какие способности срабатывают под капотом |
| Системы | Какие архитектурные элементы обеспечивают capabilities |

### 5.4. Почему blueprint особенно полезен

Он помогает избежать ошибки, когда команда проектирует только UI. На blueprint видно, что любой видимый шаг во ВКУС требует backstage capabilities и системной поддержки.

Например:

| Видимый элемент | Что нужно под капотом |
|---|---|
| Поле описания задачи | Intent classification, словарь намерений, связь с каталогом услуг |
| Короткий ответ | База знаний, RAG/search, качество источников |
| Предзаполненная карточка | IAM, HR, CMDB, prefill service, validation rules |
| Понятный статус | ITSM status normalization, notification service, user status dictionary |
| Оценка результата | Event tracking, analytics, feedback backlog |

---

## 6. Мини-матрица трассировки diagram-to-architecture

Эта таблица нужна рядом с диаграммами. Она делает связь формальной.

| Шаг клиентского пути | Capability | Что делает витрина | Архитектурные компоненты | Метрика |
|---|---|---|---|---|
| Вход во ВКУС | CAP-01 | Дает единый сервисный вход | ВКУС, задачная главная, SSO | Доля входов через ВКУС |
| Описание задачи | CAP-02 | Понимает намерение пользователя | Intent service, Search/LLM layer, каталог услуг | Intent accuracy, reclass rate |
| Быстрая помощь | CAP-03, CAP-09 | Предлагает ответ или инструкцию | База знаний, RAG/search, knowledge governance | Deflection rate, helpfulness |
| Создание обращения | CAP-04, CAP-05 | Предзаполняет форму и передает контекст | Prefill service, IAM, HR, CMDB, ITSM | Time to submit, clarification rate |
| Исполнение | CAP-05 | Передает обращение в правильную группу | ITSM / Creatio, routing rules, service catalog | Reassignment rate |
| Ожидание | CAP-06, CAP-07 | Показывает понятный статус и следующий шаг | Status/event service, ITSM, notifications | CSAT по ожиданию |
| Получение результата | CAP-06 | Показывает результат в понятном виде | ITSM, ВКУС, шаблоны результата | FCR, reopen rate |
| Оценка | CAP-08, CAP-10 | Собирает обратную связь и события пути | Data Mart, BI, feedback backlog | CSAT, feedback-to-backlog |
| Улучшение | CAP-08, CAP-09, CAP-10 | Выявляет, что улучшать | Text analytics, knowledge governance, service catalog | Доля улучшенных карточек/инструкций |

---

## 7. Как использовать этот комплект в работе команды

### 7.1. Для обсуждения с бизнесом / владельцем сервиса

Показывать прежде всего:

1. Capability-легенду.
2. Customer Journey Flow.
3. Таблицу трассировки.

Главный тезис:

```text
Мы проектируем не новый канал общения, а витрину сервисного входа, которая меняет путь пользователя.
```

### 7.2. Для обсуждения с архитекторами

Показывать:

1. C4 Context.
2. Blueprint.
3. Вопросы по границам целевой системы.

Главный тезис:

```text
Нужно определить границы целевой системы и решить, какие слои являются частью ВКУС, а какие — внешними сервисами.
```

### 7.3. Для обсуждения с UX / CX

Показывать:

1. Customer Journey Flow.
2. Blueprint.
3. Метрики на каждом шаге.

Главный тезис:

```text
Видимый интерфейс должен снижать усилия пользователя, а не переносить анкетирование в новую форму.
```

### 7.4. Для обсуждения с командой данных

Показывать:

1. CAP-08 и CAP-10.
2. Analytics / Data Mart / BI в C4 Context.
3. MVP 0 / Data Discovery.

Главный тезис:

```text
Без анализа текстов обращений, ответов поддержки и логов действий невозможно доказательно выбрать пилот и управлять улучшением пути.
```

---

## 8. Вопросы для следующей итерации

Перед переходом к C4 Container Diagram нужно согласовать несколько решений.

| № | Вопрос | Возможные варианты | Почему важно |
|---:|---|---|---|
| 1 | Где граница целевой системы? | Только ВКУС frontstage / ВКУС + backend capabilities / отдельная платформа сервисного входа | Определяет C4 Context и Container |
| 2 | Search/RAG/LLM layer — часть решения или внешний сервис? | Внутренний компонент / корпоративная AI-платформа / внешний сервис | Влияет на ответственность, безопасность и интеграции |
| 3 | Каталог услуг — внешний источник или часть capability layer? | ITSM-каталог / отдельный каталог ВКУС / общий service catalog | Влияет на mapping intent → service |
| 4 | Где живет prefill service? | ВКУС / интеграционный слой / отдельный сервис | Влияет на интеграции с IAM, HR, CMDB |
| 5 | Кто владеет статусной моделью? | ITSM / ВКУС / совместная модель | Влияет на CAP-06 и CAP-07 |
| 6 | Analytics/Data Mart — часть решения или корпоративный слой? | Локальный data mart / корпоративная платформа / BI над выгрузками | Влияет на MVP 0 и CAP-08 |
| 7 | Как фиксируем feedback loop? | Backlog улучшений / ITSM-задачи / отдельный governance-процесс | Влияет на CAP-10 |

---

## 9. Что не стоит делать на этом этапе

### Не стоит сразу делать C4 Container

Container-уровень полезен только после согласования:

- границ целевой системы;
- состава capabilities;
- роли ВКУС;
- роли Search/RAG/LLM;
- роли ITSM;
- роли Data Mart / BI.

### Не стоит превращать flow в техническую sequence diagram

Пока важно сохранить читаемость для команды. Детальные последовательности вызовов API появятся позже.

### Не стоит перегружать C4 Context capabilities

На C4 Context достаточно указывать CAP-теги возле ключевых систем. Подробная связь должна жить в traceability matrix.

---

## 10. Рекомендуемый следующий шаг

Следующая итерация должна дать два результата:

1. **Согласованную границу целевой системы.**  
   Что входит в «Витрину сервисного входа ВКУС», а что считается внешними системами.

2. **Первую C4 Container Diagram.**  
   Уже не только контекст, а внутренние контейнеры целевой системы:
   - Frontend / ВКУС UI;
   - Scenario & Intent Service;
   - Knowledge/Search Service;
   - Form & Prefill Service;
   - Integration/API Gateway;
   - Status/Event Service;
   - Analytics/Event Tracking;
   - Feedback/Improvement Backlog.

---

## 11. Итоговая формулировка

Комплект диаграмм должен помогать команде видеть не только архитектуру, но и смысл архитектуры.

```text
Каждый шаг клиентского пути должен быть связан с capability.
Каждая capability должна быть связана с архитектурным компонентом.
Каждый компонент должен иметь метрику эффекта.
```

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