Initial commit: add project files and documentation
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
This commit is contained in:
Наталия
@@ -0,0 +1 @@
|
||||
.DS_Store
|
||||
@@ -0,0 +1,292 @@
|
||||
# Постановка задачи для разработчика и код-агента
|
||||
|
||||
Ты работаешь над локальным прототипом витрины сервисного входа "ВКУС". Нужно построить действующий прототип, который демонстрирует два слоя:
|
||||
|
||||
1. Пользовательская витрина обращений.
|
||||
2. Административный слой подготовки базы знаний из сырых инструкций.
|
||||
|
||||
Работай итерационно. После каждой законченной итерации прототип должен запускаться локально и быть пригодным для user-теста.
|
||||
|
||||
## Исходные данные
|
||||
|
||||
Используй данные из папки:
|
||||
|
||||
```text
|
||||
input_data/
|
||||
```
|
||||
|
||||
Там находятся:
|
||||
|
||||
- `Start data` - исходные материалы по CJM, capabilities, C4, sequence и общей методике ВКУС.
|
||||
- `Manuals` - сырые инструкции, из которых нужно строить базу знаний для RAG.
|
||||
|
||||
Также есть стартовые JSON:
|
||||
|
||||
```text
|
||||
seed_data/knowledge.json
|
||||
seed_data/services.json
|
||||
```
|
||||
|
||||
Их можно использовать как начальные демонстрационные знания и каталог услуг.
|
||||
|
||||
Не используй и не запрашивай `.env` или другие секреты. Если нужен LLM, сделай работу через переменные окружения и fallback без LLM.
|
||||
|
||||
## Цель прототипа
|
||||
|
||||
Пользователь описывает проблему своими словами. Витрина должна:
|
||||
|
||||
1. Принять свободное описание.
|
||||
2. Найти релевантные знания в базе инструкций.
|
||||
3. Определить намерение пользователя.
|
||||
4. Подобрать подходящую услугу из каталога.
|
||||
5. Сформировать короткую рекомендацию.
|
||||
6. Подготовить черновик обращения с предзаполненными полями.
|
||||
7. Показать компактную трассировку взаимодействий: RAG, intent, service mapping, LLM/fallback, prefill.
|
||||
|
||||
Главная витрина не должна выглядеть как отладочная панель RAG. Детальный вывод источников и управление знаниями должны быть вынесены в административный инструмент.
|
||||
|
||||
## Пользовательская витрина
|
||||
|
||||
Сделай локальное web-приложение, например на Python `http.server` или другом простом стеке без тяжелой инфраструктуры.
|
||||
|
||||
Минимальный UI:
|
||||
|
||||
- поле для описания проблемы;
|
||||
- несколько кнопок с примерами;
|
||||
- кнопка "Проанализировать";
|
||||
- блок результата:
|
||||
- рекомендация;
|
||||
- шаги, если применимо;
|
||||
- подобранная услуга;
|
||||
- намерение и уверенность;
|
||||
- черновик обращения;
|
||||
- компактная трассировка.
|
||||
|
||||
Не показывай пользователю длинные RAG-фрагменты, сырой JSON, список всех источников, score-таблицы и диагностические дампы. Это можно оставить только в трассировке в сжатом виде.
|
||||
|
||||
Пример пользовательского запроса для проверки:
|
||||
|
||||
```text
|
||||
В ЛИМС не вижу проект SAP PPM, хотя он должен быть доступен для работы.
|
||||
```
|
||||
|
||||
Ожидаемое поведение:
|
||||
|
||||
- витрина должна найти контекст в инструкциях ЛИМС;
|
||||
- подобрать услугу поддержки ЛИМС;
|
||||
- предложить создание обращения или понятный следующий шаг;
|
||||
- показать, что RAG и service mapping участвовали в обработке.
|
||||
|
||||
## RAG и база знаний
|
||||
|
||||
Создай отдельный административный инструмент для подготовки базы знаний.
|
||||
|
||||
Источник данных:
|
||||
|
||||
```text
|
||||
input_data/Manuals
|
||||
```
|
||||
|
||||
Структура подпапок внутри `Manuals` не является контрактом. Она нужна человеку для удобства раскладки файлов.
|
||||
|
||||
Поддержи извлечение текста как минимум из:
|
||||
|
||||
- PDF;
|
||||
- DOCX;
|
||||
- PPTX;
|
||||
- XLSX;
|
||||
- TXT.
|
||||
|
||||
Архивы `.7z` можно поддержать технически, но пароль должен передаваться через переменную окружения. Если архив не читается, он не должен ломать весь прогон индексации.
|
||||
|
||||
## Что такое индексация
|
||||
|
||||
Индексация - это конвейер:
|
||||
|
||||
```text
|
||||
сырой файл
|
||||
-> извлечение текста
|
||||
-> очистка текста
|
||||
-> разбиение на knowledge items
|
||||
-> определение метаданных
|
||||
-> сохранение нормализованной базы знаний
|
||||
-> использование в поиске
|
||||
```
|
||||
|
||||
Минимальная структура knowledge item:
|
||||
|
||||
```json
|
||||
{
|
||||
"id": "...",
|
||||
"title": "...",
|
||||
"summary": "...",
|
||||
"text": "...",
|
||||
"system": "ЛИМС НИОКР",
|
||||
"source_file": "...",
|
||||
"source_type": "pdf",
|
||||
"section": "Страница 1",
|
||||
"content_type": "instruction",
|
||||
"content_type_title": "Инструкция",
|
||||
"module": "...",
|
||||
"role": "...",
|
||||
"source_ref": "file / section",
|
||||
"keywords": [],
|
||||
"self_service": true
|
||||
}
|
||||
```
|
||||
|
||||
Внутренние коды типов знаний должны быть стабильными на английском языке, а UI должен показывать русские названия.
|
||||
|
||||
Создай общий справочник типов знаний:
|
||||
|
||||
```json
|
||||
[
|
||||
{"code": "instruction", "title": "Инструкция"},
|
||||
{"code": "faq", "title": "Частые вопросы"},
|
||||
{"code": "troubleshooting", "title": "Решение проблем"},
|
||||
{"code": "role", "title": "Роли и доступы"},
|
||||
{"code": "reference", "title": "Справочная информация"},
|
||||
{"code": "table", "title": "Таблица"},
|
||||
{"code": "integration", "title": "Интеграция"},
|
||||
{"code": "architecture", "title": "Архитектура"}
|
||||
]
|
||||
```
|
||||
|
||||
API и UI должны возвращать и использовать оба значения:
|
||||
|
||||
```json
|
||||
{
|
||||
"content_type": "integration",
|
||||
"content_type_title": "Интеграция"
|
||||
}
|
||||
```
|
||||
|
||||
## Административный UI базы знаний
|
||||
|
||||
Сделай отдельный локальный web-ui администратора.
|
||||
|
||||
Функции:
|
||||
|
||||
- выбрать стартовую директорию;
|
||||
- выполнить полную пересборку базы знаний;
|
||||
- добавить только новые источники;
|
||||
- увидеть статистику индекса;
|
||||
- увидеть диагностику ошибок и пропусков;
|
||||
- увидеть проиндексированные документы деревом каталогов с collapse/expand;
|
||||
- исключить выбранный источник из базы знаний без удаления физического файла.
|
||||
|
||||
Важно: удаление из базы знаний не должно удалять исходный файл с диска.
|
||||
|
||||
## Manifest источников
|
||||
|
||||
Добавь manifest источников, например:
|
||||
|
||||
```json
|
||||
{
|
||||
"schema_version": "knowledge-source-manifest.v1",
|
||||
"manuals_dir": "...",
|
||||
"updated_at": "...",
|
||||
"sources": [
|
||||
{
|
||||
"source_file": "Manuals/ЛИМС/example.pdf",
|
||||
"path": "...",
|
||||
"extension": ".pdf",
|
||||
"size": 12345,
|
||||
"modified_at": "...",
|
||||
"hash": "...",
|
||||
"status": "indexed",
|
||||
"items_count": 10,
|
||||
"indexed_at": "..."
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
Поддержи статусы:
|
||||
|
||||
- `indexed` - источник входит в базу знаний;
|
||||
- `excluded` - источник исключен администратором и не должен автоматически возвращаться при добавлении новых файлов.
|
||||
|
||||
Режимы:
|
||||
|
||||
- `Полная пересборка` - заново читает стартовую директорию, но сохраняет excluded-источники.
|
||||
- `Добавить новые` - индексирует только ранее неизвестные файлы.
|
||||
- `Исключить источник` - удаляет knowledge items этого источника из базы знаний и помечает источник как excluded.
|
||||
|
||||
## Поиск
|
||||
|
||||
Для MVP можно сделать локальный keyword/hybrid-like поиск без vectorDB:
|
||||
|
||||
- токенизация запроса и текста;
|
||||
- overlap/coverage score;
|
||||
- бонусы за совпадение в title, system, module, content_type;
|
||||
- ограничение количества результатов из одного source_file;
|
||||
- возврат score и source_ref.
|
||||
|
||||
В дальнейшем решение должно быть совместимо с переносом в PostgreSQL и pgvector.
|
||||
|
||||
## Связка витрины и базы знаний
|
||||
|
||||
Пользовательская витрина должна читать базу, созданную административным инструментом. Если база недоступна, допустим fallback на seed knowledge.
|
||||
|
||||
Желательно добавить hot-reload по времени изменения JSON-файла, чтобы витрина подхватывала обновления базы знаний без перезапуска.
|
||||
|
||||
## API
|
||||
|
||||
Минимальные endpoint'ы витрины:
|
||||
|
||||
```text
|
||||
POST /api/analyze
|
||||
POST /api/search
|
||||
GET /health
|
||||
```
|
||||
|
||||
Минимальные endpoint'ы админки:
|
||||
|
||||
```text
|
||||
GET /api/status
|
||||
GET /api/documents
|
||||
GET /api/errors
|
||||
GET /api/manifest
|
||||
GET /api/reference/knowledge-types
|
||||
POST /api/reindex
|
||||
POST /api/add-new
|
||||
POST /api/delete-source
|
||||
POST /api/search
|
||||
```
|
||||
|
||||
## LLM
|
||||
|
||||
Если доступны переменные окружения для LLM, можно вызывать внешний LLM для формулирования ответа. Но прототип обязан работать без LLM:
|
||||
|
||||
- RAG-поиск локальный;
|
||||
- intent/service mapping локальные;
|
||||
- fallback-ответ формируется локальной логикой.
|
||||
|
||||
Не храни ключи в репозитории.
|
||||
|
||||
## Критерии готовности MVP
|
||||
|
||||
1. Витрина запускается локально и позволяет выполнить сценарий `/api/analyze`.
|
||||
2. Админка запускается локально и умеет собрать базу знаний из `Manuals`.
|
||||
3. База знаний строится из реальных документов.
|
||||
4. Витрина использует базу знаний, созданную админкой.
|
||||
5. Можно добавить новые источники без полной пересборки.
|
||||
6. Можно исключить ошибочный источник из базы знаний.
|
||||
7. Типы знаний показываются на русском, но внутренние коды остаются стабильными.
|
||||
8. `.env` и секреты не требуются для запуска fallback-сценария.
|
||||
|
||||
## Рекомендуемая последовательность работ
|
||||
|
||||
1. Создать минимальную витрину и endpoint `/api/analyze` на seed data.
|
||||
2. Добавить индексатор документов из `Manuals`.
|
||||
3. Добавить базу знаний JSON и endpoint `/api/search`.
|
||||
4. Подключить витрину к базе знаний.
|
||||
5. Создать админку базы знаний.
|
||||
6. Добавить manifest, `Добавить новые`, `Исключить источник`.
|
||||
7. Упростить пользовательскую витрину: убрать отладочный RAG-дамп, оставить компактную трассировку.
|
||||
8. Прогнать user-тесты на сценариях ЛИМС, 1С и восстановление файла.
|
||||
|
||||
## Важное ограничение
|
||||
|
||||
Это прототип. Не усложняй инфраструктуру раньше времени. PostgreSQL, pgvector, OCR, очереди задач и полноценный RBAC стоит проектировать как следующий этап после стабилизации JSON-модели и пользовательского сценария.
|
||||
@@ -0,0 +1,31 @@
|
||||
# Local Prototype Handoff
|
||||
|
||||
Ограниченный набор материалов для передачи разработчику и его код-агенту.
|
||||
|
||||
## Что внутри
|
||||
|
||||
```text
|
||||
input_data/
|
||||
Start data/ - исходные материалы по CJM, capabilities, C4 и sequence
|
||||
Manuals/ - сырые инструкции для будущего RAG-слоя
|
||||
|
||||
seed_data/
|
||||
knowledge.json - стартовые демонстрационные знания
|
||||
services.json - стартовый каталог услуг для service mapping
|
||||
|
||||
PROMPT_FOR_CODE_AGENT.md - постановка задачи для разработчика и код-агента
|
||||
```
|
||||
|
||||
## Что намеренно исключено
|
||||
|
||||
- `.env` и любые секреты.
|
||||
- Готовая реализация текущего прототипа.
|
||||
- Сгенерированные индексы знаний.
|
||||
- Локальные служебные файлы и кеши.
|
||||
|
||||
## Как использовать
|
||||
|
||||
1. Передать разработчику всю папку `local_prototype`.
|
||||
2. Открыть `PROMPT_FOR_CODE_AGENT.md`.
|
||||
3. Использовать его как стартовый промпт для код-агента в новом рабочем каталоге.
|
||||
4. В качестве исходных данных использовать только файлы из `input_data` и `seed_data`.
|
||||
Binary file not shown.
Binary file not shown.
Binary file not shown.
Binary file not shown.
Binary file not shown.
Binary file not shown.
@@ -0,0 +1,4 @@
|
||||
Meridium 4 https://s001as-apmapp.sibur.local/Meridium/ Основная система Meridium 4.
|
||||
Отчёты Meridium 4 https://s001as-apmrep.sibur.local/ReportServer Сервер отчётов Meridium 4.
|
||||
ЕСУИД https://idmoam.sibur.local/identity Единая система управления идентификациями.
|
||||
ВКУС https://vkus.sibur.local/ Система создания обращений в ИТ-поддержку.
|
||||
Binary file not shown.
BIN
Binary file not shown.
Binary file not shown.
Binary file not shown.
Binary file not shown.
Binary file not shown.
Binary file not shown.
File diff suppressed because it is too large
Load Diff
Binary file not shown.
Binary file not shown.
Binary file not shown.
Binary file not shown.
Binary file not shown.
Binary file not shown.
Binary file not shown.
Binary file not shown.
Binary file not shown.
@@ -0,0 +1,12 @@
|
||||
Исторический периметр, старые предприятия: Plant
|
||||
АО "Воронежсинтезкаучук" Meridium 4 1020
|
||||
АО "ПОЛИЭФ" Meridium 4 1270
|
||||
АО "Сибур-Нефтехим" Meridium 4 1230
|
||||
АО "СибурТюменьГаз", ООО "Южно-Приобский ГПЗ", "Няганьгазпереработка" Meridium 4 1040
|
||||
ООО "ЗапСибТрансГаз" Meridium 4 2070
|
||||
АО "Сибур-Химпром" Meridium 4 1240
|
||||
ООО "Запсибнефтехим" Meridium 4 1130,1120
|
||||
ООО "СИБУР" Meridium 4
|
||||
ООО "Сибур-Кстово"/ ООО "Русвинил" Meridium 4 1260
|
||||
ООО "Томскнефтехим" Meridium 4 1010
|
||||
ООО "СИБУР РТ" Meridium 4
|
||||
Binary file not shown.
Binary file not shown.
Binary file not shown.
Binary file not shown.
BIN
Binary file not shown.
BIN
Binary file not shown.
Binary file not shown.
BIN
Binary file not shown.
@@ -0,0 +1,106 @@
|
||||
|
||||
ACA Asset Criticality Analysis Анализ критичности активов
|
||||
ASM Asset Strategy Management Управление стратегией активов
|
||||
ASI Asset Strategy Implementation Реализация стратегии активов
|
||||
FMEA Failure Mode and Effects Analysis Анализ видов отказов и последствий
|
||||
RCA Root Cause Analysis
|
||||
Анализ коренных причин
|
||||
|
||||
RCM Reliability-Centered Maintenance Анализ ТО, направленное на обеспечение надёжности оборудования
|
||||
PLA Production Loses Analysis Учёт производственных потерь
|
||||
|
||||
|
||||
|
||||
АБК Административно-бытовой комплекс
|
||||
АРМ Автоматизированное рабочее место
|
||||
АСКУЭ Автоматизированная система коммерческого учёта электроэнергии
|
||||
АСТУЭ Автоматизированная система технического учёта электроэнергии
|
||||
АСУТП Автоматизированная система управления технологическим процессом
|
||||
АЦП Аналоговый цифровой преобразователь
|
||||
БД База данных
|
||||
ВКУС Витрина корпоративных услуг СИБУРа
|
||||
ГГС Громкоговорящая связь
|
||||
ГД Группа доступа
|
||||
ДЗО Дочернее зависимое общество
|
||||
ДМД Допустимый маржинальный доход
|
||||
ЕДС Единая диспетчерская служба
|
||||
ЕДДС Единая дежурная диспетчерская служба
|
||||
ЕО Единица оборудования
|
||||
ЕСУИД Единая система управления идентификационными данными пользователей
|
||||
ИПР Индивидуальный план развития
|
||||
ИС Информационная система
|
||||
КИПиА Контрольно-измерительные приборы и автоматика
|
||||
КИС Корпоративная информационная система
|
||||
КЛП\КП Ключевой пользователь
|
||||
КПЭ Ключевые показатели эффективности
|
||||
КСПД Корпоративная сеть передачи данных
|
||||
КЦ Корпоративный центр
|
||||
МАРМ Мобильный АРМ
|
||||
МО Мобильный офис
|
||||
МСЭ Межсетевой экран
|
||||
МУ Менеджер услуги / Методические указания
|
||||
ОС Обратная связь / Операционная система
|
||||
ПК Программный комплекс
|
||||
ПМИ Программа и методика испытаний
|
||||
ПО Программное обеспечение
|
||||
ППР Планово-предупредительные работы
|
||||
ПСС Производственная Система СИБУРа
|
||||
ПРМ Поддержка рабочих мест
|
||||
РВД Работа выходного дня
|
||||
РДУ Региональное диспетчерское управление
|
||||
РЗА Релейная защита и автоматика
|
||||
РП Руководитель проекта/Руководитель практики
|
||||
СБК Служебно-бытовой корпус
|
||||
СКУД Система контроля и управления доступом
|
||||
СМ Мониторинг состояния (system monitoring) / сервис менеджер
|
||||
СМИК Система мониторинга инженерных конструкций
|
||||
СМИС Система мониторинга инженерных сооружений
|
||||
СОП Стандартные операционные процедуры
|
||||
СОРС Система оперативной радиосвязи
|
||||
СПО Специальное/специализированное программное обеспечение
|
||||
СПП Служба Поддержки Пользователей
|
||||
СППР Система поддержки принятия решений
|
||||
СРК Система резервного копирования
|
||||
СРР Стандарт работы руководителя
|
||||
СС Сервер сопряжения
|
||||
СТП Стандарт Предприятия
|
||||
СУКС Система связи и управления в кризисных ситуациях
|
||||
СУН Служба Управления Надёжностью
|
||||
СУОФ Служба Управления Основными Фондами
|
||||
СУР Сверхурочная работа
|
||||
ТО Техническое обслуживание
|
||||
ТОИР Тех. Обслуживание И Ремонт
|
||||
ТП Техническая площадка / Тех. Поддержка
|
||||
ТПП Техническая поддержка пользователей
|
||||
УЗ Учетная запись
|
||||
УМД Упущенный маржинальный доход
|
||||
УМШ Улучшение малыми шагами
|
||||
УОР Увеличенный объем работ
|
||||
УПП Удаленная поддержка пользователей
|
||||
УРВ Учет рабочего времени
|
||||
УУРЗА Учет устройств релейной защиты и автоматики
|
||||
ЦИТ Центр информационных технологий
|
||||
ЦОД Центр обработки данных
|
||||
ШК Штрих-код
|
||||
ШТК Шкаф телекоммуникационный
|
||||
ШФЛУ Широкая фракция лёгких углеводородов
|
||||
ЭД Электронный документооборот
|
||||
ЭЦП Электронная цифровая подпись
|
||||
AD ActiveDirectory
|
||||
MES Manufacturing execution system, система управления производственными процессами
|
||||
LIMS Laboratory Information Management System, управление лабораторными потоками работ и документов
|
||||
R&D Research and development, НИОКР
|
||||
НиКонОР Наблюдение и Контроль Остановочного Ремонта
|
||||
МАКАР Мобильный Автоматизированный Комплекс Аудита Работ
|
||||
ПСИ Приемо-сдаточные испытания
|
||||
|
||||
|
||||
ЕО Единица обслуживания
|
||||
|
||||
|
||||
основные задачи.
|
||||
1. Пересмотр текущих стратегий технического обслуживания оборудования.
|
||||
2. Расследование причин отказов.
|
||||
3. Выдаются рекомендацию по избежание повторных отказов на основе анализа корневых причин.
|
||||
4. Анализ производства, причин снижения производительности.
|
||||
5. Формирование отчётности и графического отображения полученной информации.
|
||||
Binary file not shown.
BIN
Binary file not shown.
BIN
Binary file not shown.
BIN
Binary file not shown.
BIN
Binary file not shown.
BIN
Binary file not shown.
BIN
Binary file not shown.
BIN
Binary file not shown.
BIN
Binary file not shown.
BIN
Binary file not shown.
BIN
Binary file not shown.
Binary file not shown.
BIN
Binary file not shown.
BIN
Binary file not shown.
BIN
Binary file not shown.
BIN
Binary file not shown.
BIN
Binary file not shown.
BIN
Binary file not shown.
BIN
Binary file not shown.
BIN
Binary file not shown.
BIN
Binary file not shown.
BIN
Binary file not shown.
BIN
Binary file not shown.
BIN
Binary file not shown.
BIN
Binary file not shown.
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: тотальный анализ обращений, ответов поддержки и логов действий**. Только после этого выбирается пилотная услуга и запускается проверка на ограниченном сценарии.
|
||||
@@ -0,0 +1,72 @@
|
||||
[
|
||||
{
|
||||
"id": "kb-vpn-001",
|
||||
"title": "Не работает подключение к корпоративной сети VPN",
|
||||
"summary": "Проверьте доступ в интернет, перезапустите VPN-клиент и убедитесь, что двухфакторная аутентификация подтверждена. Если ошибка повторяется, нужна заявка с текстом ошибки и временем последней попытки.",
|
||||
"keywords": ["vpn", "удаленный доступ", "2fa", "токен", "подключение", "сеть"],
|
||||
"steps": [
|
||||
"Проверьте, открываются ли внешние сайты без VPN.",
|
||||
"Перезапустите VPN-клиент и повторите вход.",
|
||||
"Подтвердите вход через 2FA/токен.",
|
||||
"Если вход не прошел, приложите скриншот ошибки."
|
||||
],
|
||||
"self_service": true,
|
||||
"owner": "Владелец знаний: инфраструктура рабочих мест"
|
||||
},
|
||||
{
|
||||
"id": "kb-hardware-001",
|
||||
"title": "Выдача, замена или установка ИТ-оборудования",
|
||||
"summary": "Для дополнительного оборудования нужно проверить нормы положенности, указать обоснование, место установки и сотрудника, за которым закрепляется оборудование.",
|
||||
"keywords": ["монитор", "док станция", "мышь", "клавиатура", "ноутбук", "оборудование", "замена", "выдача"],
|
||||
"steps": [
|
||||
"Уточните тип оборудования и бизнес-обоснование.",
|
||||
"Проверьте соответствие матрице норм положенности.",
|
||||
"Укажите место установки и получателя.",
|
||||
"Приложите согласование руководителя, если оно требуется."
|
||||
],
|
||||
"self_service": false,
|
||||
"owner": "Владелец услуги: рабочие места"
|
||||
},
|
||||
{
|
||||
"id": "kb-password-001",
|
||||
"title": "Сброс пароля и проблемы входа",
|
||||
"summary": "Если пароль забыт или учетная запись заблокирована, сначала попробуйте самостоятельный сброс. Если не получается, заявка должна содержать логин, систему и текст ошибки.",
|
||||
"keywords": ["пароль", "логин", "учетная запись", "заблокирован", "вход", "доступ"],
|
||||
"steps": [
|
||||
"Проверьте раскладку клавиатуры и Caps Lock.",
|
||||
"Попробуйте самостоятельный сброс пароля.",
|
||||
"Если учетная запись заблокирована, создайте обращение с названием системы.",
|
||||
"Не передавайте пароль в тексте обращения."
|
||||
],
|
||||
"self_service": true,
|
||||
"owner": "Владелец знаний: IAM"
|
||||
},
|
||||
{
|
||||
"id": "kb-files-001",
|
||||
"title": "Восстановление информации на файловом ресурсе",
|
||||
"summary": "Для восстановления файла укажите путь к папке, имя файла, примерную дату удаления или изменения и нужную версию.",
|
||||
"keywords": ["файл", "папка", "сетевой диск", "восстановить", "удалил", "ресурс"],
|
||||
"steps": [
|
||||
"Укажите полный путь к файловому ресурсу.",
|
||||
"Укажите имя файла или папки.",
|
||||
"Напишите примерную дату удаления или изменения.",
|
||||
"Проверьте, не лежит ли файл в корзине или архивной копии."
|
||||
],
|
||||
"self_service": false,
|
||||
"owner": "Владелец услуги: файловые ресурсы"
|
||||
},
|
||||
{
|
||||
"id": "kb-software-001",
|
||||
"title": "Не работает программное обеспечение",
|
||||
"summary": "Перед созданием обращения проверьте перезапуск приложения и компьютера. Для заявки нужны название ПО, версия, действие, на котором возникает ошибка, и скриншот.",
|
||||
"keywords": ["программа", "приложение", "по", "ошибка", "не запускается", "зависает", "aspen", "1c"],
|
||||
"steps": [
|
||||
"Перезапустите приложение.",
|
||||
"Если проблема сохранилась, перезагрузите компьютер.",
|
||||
"Зафиксируйте текст ошибки и действие, на котором она появляется.",
|
||||
"Создайте обращение с названием ПО и скриншотом."
|
||||
],
|
||||
"self_service": true,
|
||||
"owner": "Владелец знаний: поддержка ПО"
|
||||
}
|
||||
]
|
||||
@@ -0,0 +1,67 @@
|
||||
[
|
||||
{
|
||||
"id": "svc-hardware",
|
||||
"name": "Выдача / замена / установка комплектующих",
|
||||
"category": "ИТ-оборудование и офисные сервисы",
|
||||
"intent": "Запрос ИТ-оборудования",
|
||||
"description": "Заявка на монитор, док-станцию, периферию, память, HDD/SSD или замену оборудования.",
|
||||
"keywords": ["монитор", "док станция", "мышь", "клавиатура", "оборудование", "память", "ssd", "hdd"],
|
||||
"required_fields": ["Обоснование выдачи", "Место установки", "ФИО получателя", "Согласование руководителя"]
|
||||
},
|
||||
{
|
||||
"id": "svc-software-issue",
|
||||
"name": "Не работает программное обеспечение",
|
||||
"category": "ИТ-оборудование и офисные сервисы",
|
||||
"intent": "Инцидент с программным обеспечением",
|
||||
"description": "Инциденты с приложениями, ошибками запуска, зависаниями и специализированным ПО.",
|
||||
"keywords": ["программа", "приложение", "по", "ошибка", "aspen", "1c", "не запускается", "зависает"],
|
||||
"required_fields": ["Название ПО", "Текст ошибки", "Скриншот", "Когда началась проблема"]
|
||||
},
|
||||
{
|
||||
"id": "svc-access",
|
||||
"name": "Учетная запись, пароль, 2FA/Token",
|
||||
"category": "Доступы и аутентификация",
|
||||
"intent": "Проблема доступа",
|
||||
"description": "Проблемы входа, пароля, учетной записи, токена или двухфакторной аутентификации.",
|
||||
"keywords": ["пароль", "логин", "доступ", "2fa", "токен", "учетная запись", "вход"],
|
||||
"required_fields": ["Система", "Логин", "Текст ошибки", "Контакт для связи"]
|
||||
},
|
||||
{
|
||||
"id": "svc-vpn",
|
||||
"name": "Удаленный доступ / VPN",
|
||||
"category": "Сетевые сервисы",
|
||||
"intent": "Проблема подключения к VPN",
|
||||
"description": "Не подключается VPN, не проходит 2FA, нет доступа к внутренним ресурсам удаленно.",
|
||||
"keywords": ["vpn", "удаленный", "сеть", "подключение", "2fa", "токен"],
|
||||
"required_fields": ["Тип подключения", "Текст ошибки", "Время последней попытки", "Скриншот"]
|
||||
},
|
||||
{
|
||||
"id": "svc-files",
|
||||
"name": "Восстановление информации на файловом ресурсе",
|
||||
"category": "ИТ-оборудование и офисные сервисы",
|
||||
"intent": "Восстановление файла",
|
||||
"description": "Восстановление удаленных или измененных файлов на сетевых ресурсах.",
|
||||
"keywords": ["файл", "папка", "восстановить", "удалил", "сетевой диск", "ресурс"],
|
||||
"required_fields": ["Путь к ресурсу", "Имя файла", "Дата удаления/изменения", "Нужная версия"]
|
||||
},
|
||||
{
|
||||
"id": "svc-lims-niokr",
|
||||
"name": "Поддержка ЛИМС НИОКР",
|
||||
"category": "Бизнес-системы / Лабораторные системы",
|
||||
"intent": "Вопрос или инцидент по ЛИМС НИОКР",
|
||||
"description": "Помощь по работе в ЛИМС НИОКР: доступы, роли, проекты, SAP PPM, заявки, модули, оборудование, отчеты и интеграции.",
|
||||
"systems": ["ЛИМС НИОКР"],
|
||||
"keywords": ["лимс", "ниокр", "zql", "zyfra", "sap ppm", "проект", "гейт", "заявка", "роль", "доступ", "оборудование", "отчет", "интеграция", "проводник документов", "контроль качества", "фактические операции"],
|
||||
"required_fields": ["Модуль ЛИМС", "Роль пользователя", "Описание действия или ошибки", "Скриншот/пример объекта"]
|
||||
},
|
||||
{
|
||||
"id": "svc-meridium",
|
||||
"name": "Поддержка Meridium 4",
|
||||
"category": "Бизнес-системы / Управление надежностью",
|
||||
"intent": "Вопрос или инцидент по Meridium 4",
|
||||
"description": "Помощь по работе в Meridium 4: RCA, RCM, FMEA, ASM, ASI, ACA, PLA, УМД, события, рекомендации, отчеты, роли и доступы.",
|
||||
"systems": ["Meridium 4"],
|
||||
"keywords": ["meridium", "rca", "rcm", "fmea", "asm", "asi", "aca", "pla", "умд", "дмд", "событие", "расследование", "рекомендация", "отчет", "роль", "доступ", "надежность"],
|
||||
"required_fields": ["Модуль Meridium", "Предприятие/площадка", "Описание события или действия", "Скриншот/текст ошибки"]
|
||||
}
|
||||
]
|
||||
@@ -0,0 +1,168 @@
|
||||
# АРХИТЕКТУРА ЧАТ-БОТА ИТ-ПОДДЕРЖКИ
|
||||
## Версия 2.0 — На базе Beeline AI Platform
|
||||
|
||||
---
|
||||
|
||||
## Документ для передачи в разработку
|
||||
|
||||
**Дата:** 24.06.2026
|
||||
**Версия:** 2.0
|
||||
**Статус:** Утверждена к разработке
|
||||
**Ответственный:** Архитектор решения
|
||||
|
||||
---
|
||||
|
||||
## Оглавление
|
||||
|
||||
1. [Введение](#1-введение)
|
||||
2. [Обзор решения](#2-обзор-решения)
|
||||
3. [Проблема и целевая аудитория](#3-проблема-и-целевая-аудитория)
|
||||
4. [Архитектурные принципы](#4-архитектурные-принципы)
|
||||
5. [Архитектурные диаграммы](#5-архитектурные-диаграммы)
|
||||
6. [Детальное описание компонентов](#6-детальное-описание-компонентов)
|
||||
7. [Сценарии работы](#7-сценарии-работы)
|
||||
8. [Интеграции](#8-интеграции)
|
||||
9. [Синхронизация документов](#9-синхронизация-документов)
|
||||
10. [Требования к разработке](#10-требования-к-разработке)
|
||||
11. [Требования к инфраструктуре](#11-требования-к-инфраструктуре)
|
||||
12. [Мониторинг и логирование](#12-мониторинг-и-логирование)
|
||||
13. [Безопасность](#13-безопасность)
|
||||
14. [Границы MVP](#14-границы-mvp)
|
||||
15. [Метрики успеха](#15-метрики-успеха)
|
||||
16. [План реализации](#16-план-реализации)
|
||||
17. [Открытые вопросы](#17-открытые-вопросы)
|
||||
18. [Приложения](#18-приложения)
|
||||
|
||||
---
|
||||
|
||||
## 1. Введение
|
||||
|
||||
### 1.1 Цель документа
|
||||
|
||||
Данный документ содержит полное архитектурное описание чат-бота ИТ-поддержки, интегрированного с порталом «ВКУС» и платформой ИИ Beeline. Документ предназначен для команд разработки, DevOps, тестирования и эксплуатации.
|
||||
|
||||
### 1.2 Обозначения и сокращения
|
||||
|
||||
| Сокращение | Расшифровка |
|
||||
|------------|-------------|
|
||||
| RAG | Retrieval-Augmented Generation |
|
||||
| LLM | Large Language Model |
|
||||
| API | Application Programming Interface |
|
||||
| JWT | JSON Web Token |
|
||||
| ITSM | IT Service Management |
|
||||
| BPM | Business Process Management |
|
||||
| MVP | Minimum Viable Product |
|
||||
| SLA | Service Level Agreement |
|
||||
| FQDN | Fully Qualified Domain Name |
|
||||
| DB | Database |
|
||||
| UI | User Interface |
|
||||
| S3 | Simple Storage Service |
|
||||
|
||||
---
|
||||
|
||||
## 2. Обзор решения
|
||||
|
||||
### 2.1 Назначение
|
||||
|
||||
Корпоративный чат-бот для ИТ-поддержки, интегрированный в портал «ВКУС». Бот отвечает на вопросы сотрудников по 20 ИТ-системам, используя технологию RAG (Retrieval-Augmented Generation).
|
||||
|
||||
### 2.2 Ключевая ценность
|
||||
|
||||
- **24/7 поддержка** — сотрудники получают ответы в любое время
|
||||
- **Быстрый поиск** — мгновенный доступ к инструкциям и документации
|
||||
- **Снижение нагрузки** — автоматическая обработка типовых обращений
|
||||
|
||||
### 2.3 Основные компоненты
|
||||
|
||||
| Компонент | Назначение |
|
||||
|-----------|------------|
|
||||
| **ВКУС Frontend** | Виджет чата на портале ВКУС |
|
||||
| **ВКУС Backend** | Бизнес-логика, управление диалогами, создание заявок |
|
||||
| **API платформы ИИ** | Единый OpenAI‑совместимый API (apiai.sibur.local) |
|
||||
| **RAG-слой** | Docling + BERT Inference Service + Векторная БД |
|
||||
| **LLM** | gpt-oss-120b (генерация ответов) |
|
||||
| **Документы / инструкции** | Корпоративная документация и инструкции |
|
||||
| **Creatio BPM** | ITSM-система для создания заявок |
|
||||
| **Мониторинг** | Grafana + VictoriaMetrics + OpenSearch |
|
||||
|
||||
### 2.4 Принципиальная схема
|
||||
---
|
||||
|
||||
## 3. Проблема и целевая аудитория
|
||||
|
||||
### 3.1 Проблемы
|
||||
|
||||
| № | Проблема | Описание |
|
||||
|---|----------|----------|
|
||||
| 1 | Отсутствие поддержки 24/7 | ИТ-служба работает в ограниченные часы |
|
||||
| 2 | Сложность поиска информации | Базы знаний разрознены, поиск неэффективен |
|
||||
| 3 | Большое количество типовых обращений | Операторы тратят время на однотипные вопросы |
|
||||
|
||||
### 3.2 Целевая аудитория
|
||||
|
||||
| Группа | Роль | Потребности |
|
||||
|--------|------|-------------|
|
||||
| Все сотрудники компании | Пользователи чат-бота | Быстрое получение ответов по ИТ-вопросам |
|
||||
| ИТ-операторы | Обработка заявок | Получение только сложных заявок (<70% уверенности) |
|
||||
| Владельцы инструкций | Актуализация базы знаний | Регулярное обновление документации |
|
||||
|
||||
---
|
||||
|
||||
## 4. Архитектурные принципы
|
||||
|
||||
| Принцип | Описание | Обоснование |
|
||||
|---------|----------|-------------|
|
||||
| **API платформы ИИ — единая точка входа** | Все вызовы к LLM и эмбеддингам через apiai.sibur.local | Унификация, безопасность, управляемость |
|
||||
| **Separation of concerns** | Бизнес-логика в ВКУС, генерация в AI-платформе | Чёткое разделение ответственности |
|
||||
| **OpenAI‑совместимый API** | Единый стандарт для всех вызовов | Совместимость, легкость интеграции |
|
||||
| **Stateless** | Каждый запрос независим | Масштабируемость, отказоустойчивость |
|
||||
| **Единый источник данных** | Все инструкции из корпоративных документов | Актуальность, консистентность |
|
||||
| **Secure-by-default** | Аутентификация через JWT + Keycloak | Безопасность с самого начала |
|
||||
|
||||
---
|
||||
|
||||
## 5. Архитектурные диаграммы
|
||||
|
||||
### 5.1 Контекстная диаграмма (C4 Level 1)
|
||||
|
||||
```mermaid
|
||||
flowchart TB
|
||||
Employee([Сотрудник компании])
|
||||
|
||||
subgraph VKUS["Портал ВКУС"]
|
||||
Frontend[ВКУС Frontend\nReact/Vue виджет\nВзаимодействие с пользователем]
|
||||
Backend[ВКУС Backend\nБизнес-логика портала\nУправление диалогами\nСоздание заявок в ITSM]
|
||||
end
|
||||
|
||||
subgraph BeelineAI["Платформа ИИ Beeline"]
|
||||
APIPlatform["API платформы ИИ\napiai.sibur.local (10.204.128.14)\nЕдиный OpenAI‑совместимый API\nДоступ к LLM и эмбеддингам\nГенерация API-ключей"]
|
||||
|
||||
subgraph RAG_Layer["RAG-слой"]
|
||||
Docling["Docling (uc-gpu-1, 10.204.128.13)\nСервис извлечения текста\nPDF / DOC / OCR → текст\nПодготовка данных для векторизации"]
|
||||
BERT["BERT Inference Service (uc-gpu-1, 10.204.128.13)\nМикросервис эмбеддингов\nГенерация векторных представлений\nМодель BERT (768-dim)"]
|
||||
VectorDB["Векторная БД (встроена в платформу)\nХранение векторных представлений\nБыстрый поиск похожих документов\nHNSW / IVF индексация"]
|
||||
end
|
||||
|
||||
LLM["LLM (uc-gpu-1, 10.204.128.13)\ngpt-oss-120b (основная модель)\nГенерация текста\nИнтеграция с RAG-слоем\nОбработка запросов"]
|
||||
end
|
||||
|
||||
subgraph DataSources["Документы / инструкции"]
|
||||
Documents["Документы\nКорпоративные документы\nИнструкции\nРуководства"]
|
||||
end
|
||||
|
||||
subgraph ITSM["ITSM-система"]
|
||||
Creatio["Creatio BPM\nУправление заявками\nСоздание тикетов\nОбработка обращений"]
|
||||
end
|
||||
|
||||
Employee -->|Задаёт вопрос через виджет| Frontend
|
||||
Frontend -->|Вызов API| Backend
|
||||
Backend -->|Запрос к /v1/chat/completions\n(JWT токен)| APIPlatform
|
||||
|
||||
APIPlatform -->|Поиск релевантных чанков| RAG_Layer
|
||||
RAG_Layer --> Docling --> BERT --> VectorDB
|
||||
|
||||
Documents -->|Синхронизация инструкций| Docling
|
||||
|
||||
APIPlatform -->|Генерация ответа| LLM
|
||||
|
||||
Backend -->|Создание заявки\n(при уверенности < 70%)| Creatio
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 1.3 MiB |
Reference in New Issue
Block a user