Наталия
24 KiB
24 KiB
ВКУС: C4 Context, клиентский flow и связь с capabilities
Версия: v0.1
Назначение: companion-документ к PDF ВКУС_C4_context_flow_capabilities_v0.1.pdf для самостоятельного изучения командой.
Документ показывает, как связать:
клиентский путь
→ capabilities
→ архитектурные компоненты
→ метрики
Ключевая идея: диаграммы не должны быть «красивой картинкой отдельно от требований». Они должны помогать проследить, какая capability нужна на каком шаге клиентского пути и какими архитектурными элементами она реализуется.
1. Общая логика комплекта диаграмм
Для обсуждения целевой витрины сервисного входа лучше использовать не одну перегруженную схему, а набор связанных представлений:
| Артефакт | Что показывает | Зачем нужен |
|---|---|---|
| C4 Context Diagram | Границы целевой системы, акторов и внешние системы | Понять архитектурный контекст решения |
| Customer Journey Flow | Путь пользователя и включение capabilities | Понять, как меняется клиентский опыт |
| Service Blueprint Light | Пользователь / Frontstage / Backstage / Системы | Связать UX, capabilities и архитектуру |
| Traceability Matrix | Шаг CJM → capability → компонент → метрика | Сделать связь формальной и проверяемой |
Не так
Одна супер-диаграмма со всеми системами, шагами, capabilities, roadmap и стрелками.
А вот так
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-код
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-код
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. Ключевой сдвиг
Не так
Пользователь → форма → заявка → ожидание
А вот так
Пользователь → описание задачи → быстрый ответ или предзаполненная заявка → понятный статус → оценка → улучшение сервиса
Важный принцип: обращение создается не всегда. Сначала витрина пытается помочь без создания заявки.
5. Service Blueprint Light v0.1
5.1. Назначение
Blueprint-вариант лучше всего показывает связь:
путь пользователя
→ frontstage ВКУС
→ backstage capabilities
→ системы
Он полезен для совместного обсуждения UX, бизнес-аналитиками и архитекторами.
5.2. 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. Для обсуждения с бизнесом / владельцем сервиса
Показывать прежде всего:
- Capability-легенду.
- Customer Journey Flow.
- Таблицу трассировки.
Главный тезис:
Мы проектируем не новый канал общения, а витрину сервисного входа, которая меняет путь пользователя.
7.2. Для обсуждения с архитекторами
Показывать:
- C4 Context.
- Blueprint.
- Вопросы по границам целевой системы.
Главный тезис:
Нужно определить границы целевой системы и решить, какие слои являются частью ВКУС, а какие — внешними сервисами.
7.3. Для обсуждения с UX / CX
Показывать:
- Customer Journey Flow.
- Blueprint.
- Метрики на каждом шаге.
Главный тезис:
Видимый интерфейс должен снижать усилия пользователя, а не переносить анкетирование в новую форму.
7.4. Для обсуждения с командой данных
Показывать:
- CAP-08 и CAP-10.
- Analytics / Data Mart / BI в C4 Context.
- MVP 0 / Data Discovery.
Главный тезис:
Без анализа текстов обращений, ответов поддержки и логов действий невозможно доказательно выбрать пилот и управлять улучшением пути.
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. Рекомендуемый следующий шаг
Следующая итерация должна дать два результата:
-
Согласованную границу целевой системы.
Что входит в «Витрину сервисного входа ВКУС», а что считается внешними системами. -
Первую 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. Итоговая формулировка
Комплект диаграмм должен помогать команде видеть не только архитектуру, но и смысл архитектуры.
Каждый шаг клиентского пути должен быть связан с capability.
Каждая capability должна быть связана с архитектурным компонентом.
Каждый компонент должен иметь метрику эффекта.
Это позволяет перейти от обсуждения интерфейса к управляемому проектированию витрины сервисного входа.