Initial commit: add project files and documentation
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
This commit is contained in:
Наталия
Binary file not shown.
|
After Width: | Height: | Size: 48 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 47 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 56 KiB |
@@ -0,0 +1,479 @@
|
||||
# ВКУС: 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 должна быть связана с архитектурным компонентом.
|
||||
Каждый компонент должен иметь метрику эффекта.
|
||||
```
|
||||
|
||||
Это позволяет перейти от обсуждения интерфейса к управляемому проектированию витрины сервисного входа.
|
||||
Binary file not shown.
@@ -0,0 +1,109 @@
|
||||
# Sequence diagrams для витрины сервисного входа ВКУС
|
||||
|
||||
Версия: v0.1
|
||||
Назначение: показать взаимодействие элементов решения во времени в логике клиентского пути.
|
||||
|
||||
## 1. Capability-легенда
|
||||
|
||||
| ID | Capability |
|
||||
|---|---|
|
||||
| CAP-01 | Единый сервисный вход |
|
||||
| CAP-02 | Понимание намерения пользователя |
|
||||
| CAP-03 | Помощь до создания обращения |
|
||||
| CAP-04 | Предзаполнение обращения |
|
||||
| CAP-05 | Автомаршрутизация и корректное создание обращения |
|
||||
| CAP-06 | Прозрачный статус обращения |
|
||||
| CAP-07 | Уведомления и управление ожиданиями |
|
||||
| CAP-08 | Аналитика клиентского пути |
|
||||
| CAP-09 | Управление знаниями и инструкциями |
|
||||
| CAP-10 | Контур постоянного улучшения |
|
||||
|
||||
## 2. Sequence 1. Помощь до создания обращения
|
||||
|
||||
```mermaid
|
||||
sequenceDiagram
|
||||
autonumber
|
||||
actor User as Пользователь
|
||||
participant VKUS as ВКУС / витрина
|
||||
participant Intent as Scenario & Intent Layer
|
||||
participant Catalog as Каталог услуг
|
||||
participant Knowledge as Knowledge / Search / RAG
|
||||
participant Analytics as Analytics / Data Mart
|
||||
participant Backlog as Backlog улучшений
|
||||
|
||||
User->>VKUS: Описывает проблему своим языком
|
||||
Note over User,VKUS: CAP-01 Единый сервисный вход
|
||||
VKUS->>Intent: Передает текст, профиль пользователя, контекст входа
|
||||
Intent->>Intent: Определяет намерение и уверенность
|
||||
Note over Intent: CAP-02 Понимание намерения
|
||||
Intent->>Catalog: Проверяет связь намерения с услугой / сценарием
|
||||
Catalog-->>Intent: Возможный сценарий: инструкция / self-service
|
||||
Intent->>Knowledge: Запрашивает релевантные инструкции / ответы
|
||||
Knowledge-->>Intent: Возвращает источники, краткий ответ, уверенность
|
||||
Note over Knowledge: CAP-03 Помощь до обращения; CAP-09 Управление знаниями
|
||||
Intent-->>VKUS: Возвращает рекомендованный ответ и next best action
|
||||
VKUS-->>User: Показывает короткий ответ, источник, кнопки «помогло / нужна заявка»
|
||||
User->>VKUS: Нажимает «помогло»
|
||||
VKUS->>Analytics: Фиксирует событие: вопрос решен без обращения
|
||||
Note over Analytics: CAP-08 Аналитика клиентского пути
|
||||
Analytics->>Backlog: Обновляет метрики полезности знаний
|
||||
Note over Backlog: CAP-10 Контур улучшения
|
||||
```
|
||||
|
||||
## 3. Sequence 2. Создание предзаполненного обращения и прозрачный статус
|
||||
|
||||
```mermaid
|
||||
sequenceDiagram
|
||||
autonumber
|
||||
actor User as Пользователь
|
||||
participant VKUS as ВКУС / витрина
|
||||
participant Intent as Scenario & Intent Layer
|
||||
participant Prefill as Form & Prefill Layer
|
||||
participant Master as Master Data Sources
|
||||
participant ITSM as ITSM / Creatio
|
||||
participant Status as Status / Notification Layer
|
||||
participant Analytics as Analytics / Data Mart
|
||||
participant Backlog as Backlog улучшений
|
||||
|
||||
User->>VKUS: Выбирает «создать обращение» / ответ не помог
|
||||
VKUS->>Intent: Передает исходное описание, результат поиска, контекст
|
||||
Intent->>Intent: Уточняет намерение, тип обращения, уверенность
|
||||
Note over Intent: CAP-02 Понимание намерения
|
||||
Intent->>Prefill: Передает сценарий и требуемые данные
|
||||
Prefill->>Master: Запрашивает профиль, роли, подразделение, системы
|
||||
Master-->>Prefill: Возвращает доступные мастер-данные
|
||||
Prefill->>Prefill: Формирует предзаполненную карточку
|
||||
Note over Prefill: CAP-04 Предзаполнение обращения
|
||||
Prefill-->>VKUS: Возвращает карточку: заполненные поля + недостающие вопросы
|
||||
VKUS-->>User: Показывает предзаполненную карточку
|
||||
User->>VKUS: Подтверждает / дополняет данные
|
||||
VKUS->>ITSM: Создает обращение с context package
|
||||
Note over VKUS,ITSM: CAP-05 Корректное создание обращения; context package: намерение, услуга, данные, история, источники
|
||||
ITSM-->>VKUS: Возвращает номер, статус, SLA, группу исполнения
|
||||
VKUS->>Status: Передает номер обращения и статус ITSM
|
||||
Status->>Status: Переводит внутренний статус в язык пользователя
|
||||
Note over Status: CAP-06 Прозрачный статус; CAP-07 Управление ожиданиями
|
||||
Status-->>VKUS: Возвращает понятный статус и next best action
|
||||
VKUS-->>User: Показывает статус, срок, что требуется от пользователя
|
||||
ITSM-->>Status: Обновляет статус / запрашивает уточнение
|
||||
Status-->>VKUS: Передает обновление статуса или запрос данных
|
||||
VKUS-->>User: Уведомляет пользователя
|
||||
ITSM-->>VKUS: Передает итоговое решение
|
||||
VKUS-->>User: Показывает результат: что сделано, что проверить, что дальше
|
||||
User->>VKUS: Оценивает результат
|
||||
VKUS->>Analytics: Передает оценку, события пути, результат обращения
|
||||
Note over Analytics: CAP-08 Аналитика клиентского пути
|
||||
Analytics->>Backlog: Формирует кандидаты на улучшение карточек / знаний / маршрутизации
|
||||
Note over Backlog: CAP-10 Контур улучшения
|
||||
```
|
||||
|
||||
## 4. Таблица трассировки
|
||||
|
||||
| Шаг sequence | Capabilities | Архитектурные элементы | Метрики |
|
||||
|---|---|---|---|
|
||||
| Пользователь описывает проблему | CAP-01, CAP-02 | ВКУС, Scenario & Intent Layer | time to first action, intent accuracy |
|
||||
| Проверка помощи без обращения | CAP-03, CAP-09 | Knowledge/Search/RAG, база знаний, каталог услуг | deflection rate, search success |
|
||||
| Предзаполнение карточки | CAP-04 | Prefill Service, IAM/AD, HR, CMDB, ITSM history | количество ручных полей, time to submit |
|
||||
| Создание обращения с context package | CAP-05 | API Gateway, ITSM/Creatio, routing rules | reclass rate, reassignment rate |
|
||||
| Понятный статус и уведомления | CAP-06, CAP-07 | Status/Event Service, Notification Service, ITSM statuses | CSAT по ожиданию, обращения «где статус» |
|
||||
| Оценка и улучшение | CAP-08, CAP-10 | Analytics/Data Mart, BI, Backlog улучшений | FCR, reopen rate, feedback-to-backlog |
|
||||
Binary file not shown.
Binary file not shown.
@@ -0,0 +1,789 @@
|
||||
# Витрина сервисного входа ВКУС
|
||||
## Подробный методический материал: связка CJM, capabilities и архитектуры
|
||||
|
||||
**Статус:** рабочий подробный companion-документ к резюмирующему PDF.
|
||||
**Назначение:** дать команде более подробную методическую и содержательную основу для самостоятельного изучения, уточнения HLD и подготовки roadmap.
|
||||
|
||||
---
|
||||
|
||||
## 0. Краткое резюме
|
||||
|
||||
Команда проектирует не новый канал общения с техподдержкой и не отдельный интерфейс вопрос-ответ, а **витрину сервисного входа ВКУС**.
|
||||
|
||||
Целевая витрина должна менять клиентский путь пользователя:
|
||||
|
||||
```text
|
||||
Пользователь столкнулся с проблемой
|
||||
→ описал задачу своим языком
|
||||
→ получил быстрый ответ / инструкцию / сценарий / предзаполненную заявку
|
||||
→ видит понятный статус и следующий шаг
|
||||
→ получает результат
|
||||
→ подтверждает качество
|
||||
→ данные возвращаются в контур улучшения
|
||||
```
|
||||
|
||||
Ключевой принцип:
|
||||
|
||||
```text
|
||||
Изменение клиентского пути
|
||||
→ business capability
|
||||
→ data / process capability
|
||||
→ technical capability
|
||||
→ architecture component
|
||||
→ MVP
|
||||
→ metric
|
||||
```
|
||||
|
||||
Если функция не связана с конкретной болью пользователя, изменением клиентского пути и метрикой эффекта, ее нельзя считать обоснованной для roadmap.
|
||||
|
||||
---
|
||||
|
||||
## 1. Почему не начинаем с интерфейсного решения
|
||||
|
||||
### Не так
|
||||
|
||||
```text
|
||||
Нужно внедрить чат-бот / новый интерфейс для обращений в поддержку.
|
||||
```
|
||||
|
||||
### А вот так
|
||||
|
||||
```text
|
||||
Нужно спроектировать витрину сервисного входа ВКУС, которая реализует набор возможностей, необходимых для улучшения клиентского пути.
|
||||
```
|
||||
|
||||
Интерфейсный паттерн — это только способ реализации. Он может быть разным:
|
||||
|
||||
- задачная главная страница;
|
||||
- умный поиск;
|
||||
- интеллектуальная карточка обращения;
|
||||
- мастер решения;
|
||||
- подсказки по инструкциям;
|
||||
- предзаполненная форма;
|
||||
- сценарии самообслуживания;
|
||||
- быстрый переход к сотруднику поддержки;
|
||||
- прозрачный статус обращения.
|
||||
|
||||
Главный вопрос не «какой интерфейс сделать?», а:
|
||||
|
||||
> Какой пользовательский путь позволит быстрее и точнее решить обращение с минимальными усилиями пользователя?
|
||||
|
||||
---
|
||||
|
||||
## 2. Текущая проблема клиентского пути
|
||||
|
||||
Сейчас пользователь вынужден выполнять часть работы, которая на самом деле нужна не ему, а ИТ-поддержке:
|
||||
|
||||
- выбрать правильный канал;
|
||||
- понять, в какой каталог/услугу идти;
|
||||
- прочитать карточку услуги;
|
||||
- заполнить обязательные поля;
|
||||
- угадать, какие данные нужны исполнителю;
|
||||
- дождаться уточнений;
|
||||
- понять формальный статус;
|
||||
- проверить, помог ли результат.
|
||||
|
||||
### Не так
|
||||
|
||||
```text
|
||||
Пользователь должен найти правильную услугу и заполнить анкету.
|
||||
```
|
||||
|
||||
### А вот так
|
||||
|
||||
```text
|
||||
Пользователь описывает задачу, а витрина определяет лучший следующий шаг:
|
||||
ответ, инструкция, сценарий, предзаполненная заявка или передача в поддержку.
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 3. Базовая логика трассировки
|
||||
|
||||
Каждое изменение в целевом решении должно проходить полную цепочку:
|
||||
|
||||
```text
|
||||
Этап клиентского пути
|
||||
→ боль / разрыв
|
||||
→ целевое изменение
|
||||
→ business capability
|
||||
→ data / process capability
|
||||
→ technical capability
|
||||
→ architecture component
|
||||
→ metric
|
||||
→ MVP / release
|
||||
```
|
||||
|
||||
Эта цепочка нужна, чтобы:
|
||||
|
||||
- не внедрять функции без связи с клиентской ценностью;
|
||||
- не смешивать capabilities, технические компоненты и UI-паттерны;
|
||||
- показать, зачем нужна каждая архитектурная доработка;
|
||||
- связать UX, бизнес-анализ и HLD;
|
||||
- построить roadmap от клиентского пути, а не от технологий.
|
||||
|
||||
---
|
||||
|
||||
## 4. Главный рабочий артефакт: матрица трассировки
|
||||
|
||||
Матрица трассировки — основной документ для совместной работы бизнес-аналитика, UX/CX, архитектора, владельца ВКУС, владельца ITSM и команды реализации.
|
||||
|
||||
### Шаблон
|
||||
|
||||
| Этап CJM | Боль / разрыв | Целевое изменение | Business capability | Data / process capability | Technical capability | Архитектурные компоненты | Метрика | MVP |
|
||||
|---|---|---|---|---|---|---|---|---|
|
||||
|
||||
### Пример заполнения
|
||||
|
||||
| Этап CJM | Боль / разрыв | Целевое изменение | Business capability | Data / process capability | Technical capability | Архитектурные компоненты | Метрика | MVP |
|
||||
|---|---|---|---|---|---|---|---|---|
|
||||
| Пользователь ищет услугу | Не знает внутреннюю классификацию ИТ-услуг | Описывает задачу своими словами, витрина предлагает сценарий | Понимание пользовательского намерения | Корпус обращений, поисковые запросы, словарь синонимов, история реклассов | Классификация намерения, семантический поиск | ВКУС, сервис классификации, каталог услуг, API Gateway, ITSM | Reclass rate, time to submit | MVP 3 |
|
||||
| Пользователь заполняет карточку | Много обязательных полей, часть данных уже известна компании | Карточка предзаполнена, пользователь вводит только недостающее | Минимизация ручного ввода | Данные пользователя, подразделение, роль, система, история обращений | Предзаполнение формы, интеграция с мастер-данными | ВКУС, сервис предзаполнения, AD/IAM, HR, CMDB, ITSM | Количество ручных полей, time to submit | MVP 1 |
|
||||
| Пользователь ищет инструкцию | Инструкции разрознены, поиск не помогает | Витрина предлагает короткий ответ или релевантную инструкцию до создания обращения | Помощь до создания обращения | База знаний, метаданные инструкций, история типовых ответов | Поиск по знаниям, ранжирование, ответ с источником | ВКУС, база знаний, RAG/search-контур, API Gateway | Deflection rate, search success rate | MVP 2 |
|
||||
| Пользователь ожидает решение | Нет понятного статуса и следующего действия | Пользователь видит этап обработки, срок и что требуется от него | Управление статусом и ожиданиями | Статусы ITSM, SLA, комментарии, события процесса | Нормализация статусов, уведомления, next best action | ITSM, ВКУС, status/event service, notification service | CSAT по ожиданию, обращения «где статус» | MVP 4 |
|
||||
| Пользователь оценивает результат | Обратная связь не превращается в улучшения | Оценка запускает улучшение карточек, знаний и маршрутизации | Управление качеством клиентского пути | Оценки, комментарии, переоткрытия, повторные обращения | Аналитика обратной связи, кластеризация проблем | ВКУС, ITSM, Data Mart, BI | Reopen rate, FCR, CSAT | MVP 5 |
|
||||
|
||||
---
|
||||
|
||||
## 5. Нормализация понятий: что является capability, а что нет
|
||||
|
||||
### Не так
|
||||
|
||||
```text
|
||||
Capability = кнопка / экран / API / компонент / модуль.
|
||||
```
|
||||
|
||||
### А вот так
|
||||
|
||||
```text
|
||||
Capability = способность компании обеспечить нужное изменение клиентского пути.
|
||||
```
|
||||
|
||||
| Не capability | Capability |
|
||||
|---|---|
|
||||
| Кнопка на форме | Минимизация ручного ввода |
|
||||
| Поисковая строка | Помощь до создания обращения |
|
||||
| API-интеграция | Управляемая оркестрация сервисного процесса |
|
||||
| Экран статуса | Управление ожиданиями пользователя |
|
||||
| BI-отчет | Аналитика клиентского пути |
|
||||
| RAG-компонент | Поиск и использование знаний для помощи пользователю |
|
||||
| Форма обращения | Создание обращения с достаточным контекстом |
|
||||
|
||||
---
|
||||
|
||||
## 6. Capability map целевой витрины
|
||||
|
||||
### 6.1. Клиентские capabilities
|
||||
|
||||
Эти возможности описывают, что должен ощущать и получать пользователь.
|
||||
|
||||
- единый вход во ВКУС;
|
||||
- описание проблемы на языке пользователя;
|
||||
- быстрый ответ до создания обращения;
|
||||
- понятная инструкция или следующий шаг;
|
||||
- предзаполненное обращение;
|
||||
- прозрачный статус;
|
||||
- подтверждение результата.
|
||||
|
||||
### 6.2. Business capabilities поддержки
|
||||
|
||||
Эти возможности описывают, что должна уметь организация поддержки.
|
||||
|
||||
- управление каталогом услуг;
|
||||
- управление знаниями;
|
||||
- управление обращениями;
|
||||
- управление маршрутизацией;
|
||||
- управление SLA и ожиданиями;
|
||||
- управление обратной связью;
|
||||
- управление качеством клиентского пути.
|
||||
|
||||
### 6.3. Data / analytics capabilities
|
||||
|
||||
Эти возможности обеспечивают доказательную базу и постоянное улучшение.
|
||||
|
||||
- тотальный анализ текстов обращений;
|
||||
- анализ ответов техподдержки;
|
||||
- анализ комментариев и уточнений;
|
||||
- анализ логов действий пользователей;
|
||||
- анализ логов действий сотрудников поддержки;
|
||||
- выявление пользовательских намерений;
|
||||
- выявление типовых сценариев;
|
||||
- выявление проблемных карточек услуг;
|
||||
- выявление устаревших или непонятных инструкций;
|
||||
- расчет метрик клиентского пути.
|
||||
|
||||
### 6.4. Technical capabilities
|
||||
|
||||
Эти возможности должна обеспечивать ИТ-архитектура.
|
||||
|
||||
- семантический поиск;
|
||||
- поиск по базе знаний;
|
||||
- классификация намерений;
|
||||
- сопоставление намерения с услугой / инструкцией / обращением;
|
||||
- предзаполнение формы;
|
||||
- интеграция с мастер-системами;
|
||||
- интеграция с ITSM;
|
||||
- маршрутизация обращения;
|
||||
- управление статусами;
|
||||
- уведомления;
|
||||
- аналитика и мониторинг качества.
|
||||
|
||||
---
|
||||
|
||||
## 7. Целевая архитектурная рамка
|
||||
|
||||
### Не так
|
||||
|
||||
```text
|
||||
Пользователь → вопросно-ответный интерфейс → поиск ответа → ответ / заявка
|
||||
```
|
||||
|
||||
### А вот так
|
||||
|
||||
```text
|
||||
Пользователь
|
||||
→ ВКУС: витрина сервисного входа
|
||||
→ слой сценариев и намерений
|
||||
→ слой знаний и каталога услуг
|
||||
→ слой карточек и предзаполнения
|
||||
→ интеграционный слой
|
||||
→ ITSM-исполнение
|
||||
→ статусы и уведомления
|
||||
→ аналитика и улучшение качества
|
||||
```
|
||||
|
||||
### 7.1. Архитектурные слои
|
||||
|
||||
| Слой | Назначение | Примеры компонентов | Какие capabilities реализует |
|
||||
|---|---|---|---|
|
||||
| Frontstage / ВКУС | То, что видит пользователь | Задачная главная, умный поиск, карточка, мастер решения, статус, оценка | Единый вход, снижение когнитивной нагрузки, статус, feedback |
|
||||
| Scenario & Intent Layer | Понимание задачи пользователя | Intent service, scenario engine, clarification logic | Понимание намерения, выбор сценария, минимальные уточнения |
|
||||
| Knowledge & Service Catalog Layer | Помощь до обращения и связь с услугами | База знаний, каталог услуг, RAG/search-контур, service mapping | Помощь до обращения, управление знаниями, intent → service |
|
||||
| Form & Prefill Layer | Минимизация ручного ввода | Prefill service, form engine, validation rules, context package | Предзаполнение, минимальный ввод, качество заявки на входе |
|
||||
| Integration & Orchestration Layer | Управляемые интеграции | API Gateway, connectors, auth, audit, policies | Оркестрация, безопасность, аудит, устойчивость |
|
||||
| ITSM Execution Layer | Создание и исполнение обращений | ITSM / Creatio, routing, SLA, comments sync | Создание обращения, маршрутизация, SLA, исполнение |
|
||||
| Status & Notification Layer | Понятное ожидание | Status/event service, notification service, next best action | Прозрачный статус, уведомления, управление ожиданиями |
|
||||
| Analytics & Improvement Layer | Улучшение сервиса на данных | Event tracking, Data Mart, text analytics, BI, feedback loop | Аналитика пути, feedback loop, knowledge governance |
|
||||
|
||||
---
|
||||
|
||||
## 8. Целевой путь: как было / как должно стать
|
||||
|
||||
| Область | Как было | Как должно стать |
|
||||
|---|---|---|
|
||||
| Вход в поддержку | Пользователь выбирает канал и услугу | Пользователь описывает задачу, витрина предлагает сценарий |
|
||||
| Инструкции | Пользователь сам ищет и читает длинные материалы | Витрина предлагает короткий ответ, источник и следующий шаг |
|
||||
| Карточка | Пользователь заполняет анкету для поддержки | Пользователь проверяет предзаполненный контекст |
|
||||
| Маршрутизация | Ошибка выбора услуги ведет к переназначениям | Намерение сопоставляется с услугой и группой поддержки |
|
||||
| Ожидание | Пользователь видит формальный статус | Пользователь понимает этап, срок и next best action |
|
||||
| Результат | Обращение закрыто в ITSM | Пользователь подтвердил решение рабочей проблемы |
|
||||
| Улучшение | Обратная связь собирается отдельно | Обратная связь попадает в backlog улучшений |
|
||||
|
||||
---
|
||||
|
||||
## 9. Gap-analysis текущего HLD
|
||||
|
||||
Текущий HLD содержит полезное ядро:
|
||||
|
||||
- ВКУС как точку входа;
|
||||
- API Gateway;
|
||||
- LiteLLM / LLM-шлюз;
|
||||
- RAG/search-контур;
|
||||
- интеграцию с ITSM / Creatio;
|
||||
- передачу контекста;
|
||||
- первичную обратную связь.
|
||||
|
||||
Но HLD должен быть расширен от описания отдельного интерфейсного решения до архитектуры витрины сервисного входа.
|
||||
|
||||
| Capability | Покрытие в HLD | Что требуется добавить |
|
||||
|---|---|---|
|
||||
| Поиск по инструкциям | Покрыто / частично | Требования к качеству источников, актуальности, владельцам знаний |
|
||||
| Понимание намерения пользователя | Частично | Выделить intent detection как отдельную capability и компонент |
|
||||
| Сопоставление намерения с услугой | Не покрыто | Добавить mapping: intent → service / knowledge / ticket |
|
||||
| Предзаполнение обращения | Не покрыто | Добавить prefill service и интеграции с AD/IAM, HR, CMDB, ITSM |
|
||||
| Динамическая карточка | Не покрыто | Добавить form/scenario engine |
|
||||
| Прозрачный статус | Не покрыто | Добавить status/event service и UX-словарь статусов |
|
||||
| Аналитика клиентского пути | Не покрыто | Добавить event tracking, Data Mart, BI, text analytics |
|
||||
| Feedback loop | Частично | Связать оценки с backlog улучшений карточек, знаний и маршрутизации |
|
||||
|
||||
### Ключевая доработка HLD
|
||||
|
||||
### Не так
|
||||
|
||||
```text
|
||||
High-Level Design: отдельный интерфейс вопрос-ответ для ИТ-поддержки.
|
||||
```
|
||||
|
||||
### А вот так
|
||||
|
||||
```text
|
||||
High-Level Design: витрина сервисного входа ВКУС.
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 10. MVP 0: Data Discovery как обязательный старт
|
||||
|
||||
MVP 0 — это не просто сбор нескольких метрик. Это **тотальный анализ обращений, ответов поддержки и логов действий**.
|
||||
|
||||
### Не так
|
||||
|
||||
```text
|
||||
Берем одну услугу и экспертно решаем, что в ней улучшить.
|
||||
```
|
||||
|
||||
### А вот так
|
||||
|
||||
```text
|
||||
Сначала анализируем весь массив обращений, ответов и логов, строим фактическую карту проблематики, затем выбираем пилотную услугу на основании данных.
|
||||
```
|
||||
|
||||
### 10.1. Что анализируем
|
||||
|
||||
| Источник | Ценность |
|
||||
|---|---|
|
||||
| Тексты обращений | Пользовательские намерения, реальные формулировки, частотные темы |
|
||||
| Ответы поддержки | Типовые решения, повторяющиеся ответы, качество языка |
|
||||
| Комментарии | Уточнения, потеря контекста, недостающие данные |
|
||||
| Маршрутизация | Реклассы, переназначения, ошибки выбора услуги |
|
||||
| Статусы и сроки | Ожидание, задержки, зависания |
|
||||
| Переоткрытия | Где результат не решает проблему с первого раза |
|
||||
| Оценки | Качество глазами пользователя |
|
||||
| Поиск во ВКУС | Пользовательский язык поиска и пробелы каталога |
|
||||
| Логи действий во ВКУС | Открытые карточки, возвраты, незавершенные обращения |
|
||||
| Действия поддержки | Типовые ручные операции, запросы данных, смены групп |
|
||||
|
||||
### 10.2. Какие вопросы должен закрыть Data Discovery
|
||||
|
||||
| Вопрос | Зачем нужен ответ |
|
||||
|---|---|
|
||||
| Какие пользовательские намерения создают основной поток обращений? | Основа для задачной главной и intent layer |
|
||||
| Какие обращения можно было решить инструкцией без заявки? | Основа для помощи до обращения |
|
||||
| Какие данные поддержка чаще всего уточняет? | Основа для предзаполнения и динамической карточки |
|
||||
| Какие услуги чаще всего выбираются неверно? | Основа для intent → service mapping |
|
||||
| Какие ответы поддержки повторяются? | Основа для базы знаний и шаблонов решений |
|
||||
| Какие инструкции не находятся или не помогают? | Основа для knowledge governance |
|
||||
| Где пользователь теряет время до подачи обращения? | Основа для UX-улучшений ВКУС |
|
||||
| Где обращение теряет контекст между каналами и группами? | Основа для context package и ITSM-интеграции |
|
||||
| Какие сценарии дают высокий reclass / reassignment / reopen? | Основа для приоритизации MVP |
|
||||
| Какие карточки услуг являются наиболее проблемными? | Основа для выбора пилотной услуги |
|
||||
|
||||
### 10.3. Выходы MVP 0
|
||||
|
||||
- карта пользовательских намерений;
|
||||
- топ проблемных услуг / карточек;
|
||||
- список типовых недостающих данных;
|
||||
- список повторяющихся ответов поддержки;
|
||||
- список knowledge gaps;
|
||||
- карта ошибок маршрутизации;
|
||||
- baseline метрик;
|
||||
- обоснованный выбор пилотной услуги.
|
||||
|
||||
---
|
||||
|
||||
## 11. Roadmap / MVP-логика
|
||||
|
||||
Roadmap строится не от технических компонентов, а от изменений клиентского пути.
|
||||
|
||||
### Не так
|
||||
|
||||
```text
|
||||
MVP 1: поиск
|
||||
MVP 2: LLM
|
||||
MVP 3: интеграция с ITSM
|
||||
MVP 4: аналитика
|
||||
```
|
||||
|
||||
### А вот так
|
||||
|
||||
```text
|
||||
MVP 0: построить фактическую карту проблем на данных
|
||||
MVP 1: сократить ручное заполнение
|
||||
MVP 2: помочь до создания обращения
|
||||
MVP 3: убрать необходимость выбора услуги
|
||||
MVP 4: сделать ожидание прозрачным
|
||||
MVP 5: запустить контур постоянного улучшения
|
||||
```
|
||||
|
||||
| MVP | Фокус | Изменение в клиентском пути | Основные capabilities | Ключевые компоненты | Метрики |
|
||||
|---|---|---|---|---|---|
|
||||
| MVP 0 | Data Discovery | Понять фактические разрывы текущего пути | Аналитика клиентского пути | Выгрузки ВКУС/ITSM, анализ текстов, логов, Data Mart light | Baseline, reclass, clarification, reopen |
|
||||
| MVP 1 | Упрощение карточки | Быстрее и проще подать обращение | Предзаполнение, минимальный ввод | ВКУС, prefill, мастер-данные, ITSM | Time to submit, ручные поля, clarification rate |
|
||||
| MVP 2 | Помощь до обращения | Решать часть вопросов без заявки | Поиск по знаниям, управление инструкциями | Knowledge layer, search/RAG, API Gateway | Deflection, search success, helpfulness |
|
||||
| MVP 3 | Намерения | Не выбирать услугу вручную | Intent detection, service mapping, routing | Intent service, catalog, routing, ITSM | Reclass, reassignment, time to submit |
|
||||
| MVP 4 | Статус | Понятно ждать и отвечать на уточнения | Status, notifications, next best action | Status/event service, notifications | CSAT, обращения по статусу |
|
||||
| MVP 5 | Улучшение | Сервис сам выявляет, что улучшать | Analytics, feedback loop, governance | CX Data Mart, BI, text analytics | CSAT, FCR, reopen |
|
||||
|
||||
---
|
||||
|
||||
## 12. Детализация MVP
|
||||
|
||||
### 12.1. MVP 1: упрощение карточки
|
||||
|
||||
Цель — доказать, что снижение ручного ввода улучшает клиентский опыт.
|
||||
|
||||
### Не так
|
||||
|
||||
```text
|
||||
Пользователь заполняет анкету для поддержки.
|
||||
```
|
||||
|
||||
### А вот так
|
||||
|
||||
```text
|
||||
Пользователь проверяет предзаполненный контекст и добавляет только то, чего система не знает.
|
||||
```
|
||||
|
||||
Что сделать:
|
||||
|
||||
- выбрать частую и управляемую услугу;
|
||||
- измерить текущую карточку;
|
||||
- разделить поля на нужные, автозаполняемые и лишние;
|
||||
- переписать описание карточки простым языком;
|
||||
- добавить пример заполнения;
|
||||
- включить предзаполнение;
|
||||
- измерить эффект.
|
||||
|
||||
Метрики:
|
||||
|
||||
- количество ручных полей;
|
||||
- time to submit;
|
||||
- clarification rate;
|
||||
- доля автозаполненных полей;
|
||||
- CSAT по подаче.
|
||||
|
||||
### 12.2. MVP 2: помощь до обращения
|
||||
|
||||
Цель — сократить количество обращений, которые можно решить инструкцией, подсказкой или коротким ответом.
|
||||
|
||||
### Не так
|
||||
|
||||
```text
|
||||
Пользователь не знает, как сделать → ищет услугу → создает обращение.
|
||||
```
|
||||
|
||||
### А вот так
|
||||
|
||||
```text
|
||||
Пользователь не знает, как сделать → получает короткую инструкцию → создает обращение только если инструкция не помогла.
|
||||
```
|
||||
|
||||
Метрики:
|
||||
|
||||
- deflection rate;
|
||||
- search success rate;
|
||||
- helpfulness score;
|
||||
- knowledge gap rate.
|
||||
|
||||
### 12.3. MVP 3: намерения и маршрутизация
|
||||
|
||||
Цель — убрать необходимость пользователю знать внутреннюю классификацию ИТ-услуг.
|
||||
|
||||
### Не так
|
||||
|
||||
```text
|
||||
Пользователь ищет правильную услугу в каталоге.
|
||||
```
|
||||
|
||||
### А вот так
|
||||
|
||||
```text
|
||||
Пользователь описывает задачу, система предлагает сценарий, услугу, инструкцию или заявку.
|
||||
```
|
||||
|
||||
Метрики:
|
||||
|
||||
- reclass rate;
|
||||
- reassignment rate;
|
||||
- intent accuracy;
|
||||
- time to submit;
|
||||
- clarification rate.
|
||||
|
||||
### 12.4. MVP 4: прозрачный статус
|
||||
|
||||
Цель — снизить неопределенность после создания обращения.
|
||||
|
||||
### Не так
|
||||
|
||||
```text
|
||||
Пользователь получил номер обращения и ждет.
|
||||
```
|
||||
|
||||
### А вот так
|
||||
|
||||
```text
|
||||
Пользователь видит понятный статус, срок, следующий шаг и запросы к себе.
|
||||
```
|
||||
|
||||
Метрики:
|
||||
|
||||
- обращения «где статус?»;
|
||||
- CSAT по ожиданию;
|
||||
- время ответа пользователя на уточнение;
|
||||
- доля просроченных уточнений.
|
||||
|
||||
### 12.5. MVP 5: контур постоянного улучшения
|
||||
|
||||
Цель — превратить данные клиентского пути в системное улучшение витрины, карточек, инструкций и маршрутизации.
|
||||
|
||||
### Не так
|
||||
|
||||
```text
|
||||
Пользователь поставил оценку, но улучшения происходят нерегулярно.
|
||||
```
|
||||
|
||||
### А вот так
|
||||
|
||||
```text
|
||||
Оценки, тексты, логи и результаты формируют backlog улучшений.
|
||||
```
|
||||
|
||||
Метрики:
|
||||
|
||||
- feedback-to-backlog rate;
|
||||
- доля улучшенных карточек;
|
||||
- доля обновленных инструкций;
|
||||
- reopen rate;
|
||||
- FCR;
|
||||
- CSAT.
|
||||
|
||||
---
|
||||
|
||||
## 13. Метрики и критерии успеха
|
||||
|
||||
Метрики должны измерять не факт появления новой функции, а изменение клиентского пути.
|
||||
|
||||
### Не так
|
||||
|
||||
```text
|
||||
Реализовано предзаполнение карточки.
|
||||
```
|
||||
|
||||
### А вот так
|
||||
|
||||
```text
|
||||
Пользователь меньше вводит вручную, быстрее отправляет обращение, а поддержка реже запрашивает недостающие данные.
|
||||
```
|
||||
|
||||
### 13.1. Минимальный дашборд
|
||||
|
||||
| Блок | Метрика |
|
||||
|---|---|
|
||||
| Усилия пользователя | Time to submit |
|
||||
| Усилия пользователя | Количество ручных полей |
|
||||
| Поиск / помощь | Search success rate |
|
||||
| Поиск / помощь | Deflection rate |
|
||||
| Качество входа | Reclass rate |
|
||||
| Качество входа | Clarification rate |
|
||||
| Исполнение | MTTR |
|
||||
| Результат | Reopen rate |
|
||||
| Результат | FCR |
|
||||
| Опыт | CSAT |
|
||||
|
||||
### 13.2. Расширенный набор метрик
|
||||
|
||||
| Группа | Метрики |
|
||||
|---|---|
|
||||
| Усилия пользователя | time to submit, количество ручных полей, abandoned submission rate, количество открытых карточек до подачи |
|
||||
| Понимание намерения | intent accuracy, reclass rate, reassignment rate, корректность предложенной услуги |
|
||||
| Помощь до обращения | deflection rate, search success rate, helpfulness score, knowledge gap rate |
|
||||
| Качество заявки на входе | clarification rate, доля обращений без доп. вопросов, time to first action |
|
||||
| Ожидание | SLA transparency, обращения «где статус?», CSAT по ожиданию |
|
||||
| Результат | FCR, reopen rate, repeat contact rate, CSAT по результату |
|
||||
| Контур улучшения | feedback-to-backlog rate, доля улучшенных карточек, доля обновленных инструкций |
|
||||
|
||||
---
|
||||
|
||||
## 14. Данные как источник ценности
|
||||
|
||||
Анализ обращений, ответов поддержки и логов важен не только для отчетности. Это основа проектирования целевой витрины.
|
||||
|
||||
Опросы показывают восприятие клиентского пути.
|
||||
Тексты обращений, ответы и логи показывают фактическую механику процесса.
|
||||
|
||||
### 14.1. Ценность текстов обращений
|
||||
|
||||
Тексты обращений показывают:
|
||||
|
||||
- как пользователи реально называют проблемы;
|
||||
- какие формулировки используют;
|
||||
- что не указывают сразу;
|
||||
- где выбранная услуга не соответствует проблеме;
|
||||
- какие темы повторяются;
|
||||
- какие обращения можно закрывать инструкцией.
|
||||
|
||||
### 14.2. Ценность ответов поддержки
|
||||
|
||||
Ответы поддержки показывают:
|
||||
|
||||
- какие решения повторяются;
|
||||
- какие ответы можно стандартизировать;
|
||||
- какие инструкции реально используются;
|
||||
- где язык поддержки слишком технический;
|
||||
- где результат не соответствует ожиданию;
|
||||
- какие вопросы можно перевести в self-service.
|
||||
|
||||
### 14.3. Ценность комментариев
|
||||
|
||||
Комментарии показывают:
|
||||
|
||||
- какие данные приходится уточнять;
|
||||
- сколько итераций требуется;
|
||||
- где теряется контекст;
|
||||
- где пользователь не отвечает;
|
||||
- где поддержка повторно задает похожие вопросы.
|
||||
|
||||
### 14.4. Ценность логов действий пользователя
|
||||
|
||||
Логи показывают невидимую часть пути до создания обращения:
|
||||
|
||||
- поисковые запросы;
|
||||
- открытые карточки;
|
||||
- возвраты назад;
|
||||
- время на карточке;
|
||||
- начатые, но не отправленные обращения;
|
||||
- переходы между каналами;
|
||||
- точки отказа.
|
||||
|
||||
### 14.5. Ценность логов поддержки
|
||||
|
||||
Логи поддержки показывают операционную механику:
|
||||
|
||||
- переназначения;
|
||||
- реклассы;
|
||||
- время до первого действия;
|
||||
- типовые ручные операции;
|
||||
- запросы данных;
|
||||
- смену групп;
|
||||
- закрытия типовыми формулировками.
|
||||
|
||||
---
|
||||
|
||||
## 15. Рабочие задачи для команды
|
||||
|
||||
### 15.1. Ближайшие задачи
|
||||
|
||||
```text
|
||||
1. Утвердить принцип: проектируем витрину сервисного входа.
|
||||
2. Утвердить формат матрицы трассировки.
|
||||
3. Запустить тотальный анализ обращений, ответов поддержки и логов действий.
|
||||
4. На основе анализа выбрать пилотную услугу.
|
||||
5. Собрать baseline по текущей карточке пилотной услуги.
|
||||
6. Разобрать пилотную услугу детально: поля, уточнения, ошибки, маршрутизация.
|
||||
7. Спроектировать короткую предзаполненную карточку.
|
||||
8. Описать mini-HLD пилота.
|
||||
9. Запустить пилот на ограниченной группе пользователей.
|
||||
10. Измерить эффект и принять решение о масштабировании.
|
||||
```
|
||||
|
||||
### 15.2. Рабочие артефакты
|
||||
|
||||
| Артефакт | Назначение |
|
||||
|---|---|
|
||||
| Нормализованный AS IS / TO BE путь | Показать изменение клиентского опыта |
|
||||
| Матрица трассировки | Связать CJM, capabilities, архитектуру и метрики |
|
||||
| Capability map | Развести бизнес-, data-, technical capabilities |
|
||||
| Gap-analysis HLD | Понять, что есть и что нужно добавить |
|
||||
| Целевая архитектурная рамка | Описать слои витрины сервисного входа |
|
||||
| MVP-roadmap | Разложить реализацию по этапам |
|
||||
| Дашборд метрик | Измерять эффект изменений |
|
||||
|
||||
---
|
||||
|
||||
## 16. Требования к HLD
|
||||
|
||||
HLD должен быть переработан в документ:
|
||||
|
||||
```text
|
||||
High-Level Design: Витрина сервисного входа ВКУС
|
||||
```
|
||||
|
||||
В нем должны быть разделы:
|
||||
|
||||
1. Цель архитектуры и связь с клиентским путем.
|
||||
2. Capability layer.
|
||||
3. Frontstage layer ВКУС.
|
||||
4. Scenario & Intent layer.
|
||||
5. Knowledge & Service Catalog layer.
|
||||
6. Form & Prefill layer.
|
||||
7. Integration & Orchestration layer.
|
||||
8. ITSM Execution layer.
|
||||
9. Status & Notification layer.
|
||||
10. Analytics & Improvement layer.
|
||||
11. Security / audit / data protection.
|
||||
12. MVP roadmap.
|
||||
13. Метрики качества.
|
||||
|
||||
---
|
||||
|
||||
## 17. Роли и зоны ответственности
|
||||
|
||||
| Роль | Ответственность |
|
||||
|---|---|
|
||||
| Product owner / владелец витрины | Приоритизация клиентского пути и roadmap |
|
||||
| CX / UX-эксперт | CJM, сценарии, карточки, понятность статусов |
|
||||
| Бизнес-аналитик | Матрица трассировки, требования, метрики |
|
||||
| Архитектор | HLD, слои, компоненты, интеграции |
|
||||
| Владелец ITSM | Процессы обращений, статусы, SLA, маршрутизация |
|
||||
| Владелец каталога услуг | Качество услуг, карточек, связка intent → service |
|
||||
| Владелец базы знаний | Инструкции, актуальность, источники, gaps |
|
||||
| Data analyst | Аналитика обращений, логов, метрик |
|
||||
| Security / ИБ | Доступы, аудит, персональные данные, обезличивание |
|
||||
|
||||
---
|
||||
|
||||
## 18. Риски и способы контроля
|
||||
|
||||
| Риск | Как проявится | Как контролировать |
|
||||
|---|---|---|
|
||||
| Возврат к интерфейсному мышлению | Команда снова обсуждает конкретный UI вместо пути | Использовать матрицу трассировки как обязательный артефакт |
|
||||
| Слишком большой MVP | Попытка реализовать все слои сразу | Начать с одной услуги и измеримого эффекта |
|
||||
| Нет данных для baseline | Невозможно доказать улучшение | MVP 0 сделать обязательным |
|
||||
| Предзаполнение без качества данных | Подставляются неверные данные | Проверить источники и правила валидации |
|
||||
| База знаний неактуальна | Витрина дает плохие ответы | Ввести knowledge governance |
|
||||
| Статусы остаются внутренними | Пользователь не понимает «В работе» / «Назначено» | Создать пользовательский словарь статусов |
|
||||
| Метрики не имеют владельцев | Дашборд есть, улучшений нет | Назначить владельцев метрик и backlog |
|
||||
| Витрина становится новой анкетой | Пользователь проходит те же вопросы в новом интерфейсе | Ограничить ручной ввод и проверять time to submit |
|
||||
|
||||
---
|
||||
|
||||
## 19. Рабочие правила команды
|
||||
|
||||
1. Не начинать с выбора интерфейсного решения.
|
||||
2. Любая функция должна быть связана с болью клиента.
|
||||
3. Технический компонент не является capability.
|
||||
4. Интерфейсный паттерн не является бизнес-возможностью.
|
||||
5. Каждая capability должна иметь владельца и метрику.
|
||||
6. Каждое изменение HLD должно быть связано с изменением в клиентском пути.
|
||||
7. Roadmap должен начинаться с анализа данных и baseline.
|
||||
8. Гипотезы улучшений проверяются на конкретных услугах и сценариях.
|
||||
9. Витрина должна снижать усилия пользователя, а не переносить анкетирование в новый интерфейс.
|
||||
10. Целевой результат — не создание обращения, а решение пользовательской проблемы.
|
||||
|
||||
---
|
||||
|
||||
## 20. Итоговая формулировка
|
||||
|
||||
Команда проектирует не новый канал общения с поддержкой, а **витрину сервисного входа во ВКУС**.
|
||||
|
||||
Витрина должна менять клиентский путь:
|
||||
|
||||
- снижать ручной ввод;
|
||||
- помогать до создания обращения;
|
||||
- понимать намерение пользователя;
|
||||
- создавать обращения с контекстом;
|
||||
- показывать понятный статус;
|
||||
- возвращать данные в контур улучшения.
|
||||
|
||||
Каждая функция витрины должна быть связана с:
|
||||
|
||||
```text
|
||||
этапом клиентского пути
|
||||
→ business capability
|
||||
→ data / process capability
|
||||
→ technical capability
|
||||
→ архитектурным компонентом
|
||||
→ метрикой эффекта
|
||||
```
|
||||
|
||||
Первый практический шаг — **MVP 0: тотальный анализ обращений, ответов поддержки и логов действий**. Только после этого выбирается пилотная услуга и запускается проверка на ограниченном сценарии.
|
||||
Reference in New Issue
Block a user