Initial commit: add project files and documentation

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
2026-06-28 23:57:34 +07:00
commit 71537b1e63
75 changed files with 42351 additions and 0 deletions
@@ -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/ Система создания обращений в ИТ-поддержку.
@@ -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	
@@ -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. Формирование отчётности и графического отображения полученной информации.
@@ -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 должна быть связана с архитектурным компонентом.
+Каждый компонент должен иметь метрику эффекта.
+```
+
+Это позволяет перейти от обсуждения интерфейса к управляемому проектированию витрины сервисного входа.
@@ -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 |
@@ -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: тотальный анализ обращений, ответов поддержки и логов действий**. Только после этого выбирается пилотная услуга и запускается проверка на ограниченном сценарии.