Шаг 4 · Поток ценности по сценариям
Линза: где по ходу работы создаётся ценность, где она теряется и что из этого убирает витрина по ТЗ. Основа — идентификаторы из 01-roles-jtbd.md (R0–R7, S1–S6, J0–J10, SC1–SC9). Источники: materials/tz-text.md (ТЗ v1.1), personas.md, research/ui-integration.md.
Пометки: [Ф] — факт из материалов, с номером требования или раздела ТЗ; [Г] — гипотеза, проверить у заказчика. Цифр, кроме тех, что есть в ТЗ, нет. Оценки «высокая / средняя / низкая» качественные.
0. Условные обозначения потерь
Потери процесса (есть и сейчас):
| Код |
Потеря |
| О |
ожидание: кто-то ждёт (клиент на линии, бригада, сделка в очереди) |
| П |
переключение между окнами и системами |
| ПП |
повторный поиск или ручной перенос ключа (ИНН, лицевой счёт, номер наряда) из одной системы в другую |
| НС |
неверный или неполный статус называют клиенту или руководителю |
| ДС |
ради действия нужно уйти в другую систему и заново найти там объект |
| ЗГ |
знание «где смотреть и что это значит» есть только в голове у опытных |
| ПЗ |
поздний сигнал: о сбое узнают после клиента или от клиента |
Потери, которые вносит сама архитектура «роботы читают экраны по запросу»:
| Код |
Потеря |
Основание |
| А1 |
ожидание робота: обновление одного источника до 60 с, полной карточки до 120 с (целевые, не обязательные) |
[Ф] NFR-03, NFR-04 (Target) |
| А2 |
устаревший снимок: менеджер видит «актуально на 10:42» и сам решает, верить или ждать |
[Ф] FR-SRCH-04, раздел 7.3 (сроки свежести — стартовые гипотезы) |
| А3 |
дыра при сбое: источник недоступен или экран изменился — блок замораживается, пользователь возвращается к ручному пути |
[Ф] AT-05, AT-06, RPA-02, раздел 7.2 |
| А4 |
сигнал только у того, кто открыл: внеплановое обновление запускается открытием блока или приближением срока; кто следит за объектами, которые никто не открыл, не определено |
[Ф] раздел 7.3; [Г] о вероятном поведении |
| А5 |
очередь из-за лимита сессий и лицензий источников |
[Ф] RPA-08, раздел 15 «Ограничение лицензий/сессий», FR-UPD-04 |
| А6 |
смещённая аналитика: считается только то, что роботы успели собрать |
[Ф] FR-AN-04, FR-AN-06 |
| А7 |
постоянная цена в людях: администратор роботов R6 и аудитор R7 |
[Ф] разделы 3, 10, 12 |
| А8 |
учётка робота видит не то же, что человек |
[Ф] прил. А, КАИС ДК: «видимость может быть ограничена группой пользователя»; ACCESS_DENIED в 7.2 |
1. Сценарии
SC1 · «Где наш выезд?» · J1 · R1, R0
Сейчас.
1. Клиент ждал бригаду, она не пришла. Его не предупредили, он звонит менеджеру. Ценность уже потеряна до звонка (ПЗ, О у R0). [Г]
2. R1 ищет клиента в Старте по ИНН, выбирает лицевой счёт, находит наряд (П).
3. В Старте перенос не виден: данные из WFM приходят туда только при закрытии наряда [Ф прил. А, Аргус WFM]. Кто этого не знает, называет клиенту старую дату (НС, ЗГ).
4. R1 переносит номер наряда в Аргус WFM (ПП, П), читает промежуточный статус и свободный комментарий.
5. При необходимости — ДК, чтобы увидеть проект (П).
6. Ценность создаётся здесь: менеджер называет новую дату и причину. Клиент всё это время на линии (О).
По ТЗ.
- Убирает: поиск по ИНН, переключение между Стартом и ДК, ручной перенос номера наряда, связь наряда с проектом (FR-WORK-04).
- В первой фазе ключевого блока нет: WFM входит во вторую фазу, а сам показ переносов имеет приоритет Should [Ф] FR-WORK-03, раздел 14. Получается, что в первой фазе на главный вопрос сценария витрина отвечает тем же неверным статусом из Старта, только быстрее. Это нужно явно помечать в карточке, иначе витрина узаконит НС.
- Во второй фазе: перенос виден «после очередного успешного обновления» [Ф] FR-WORK-03, AT-04. Срок свежести открытых нарядов 5–15 минут [Ф] 7.3.
Остались. ПЗ у клиента: он по-прежнему узнаёт первым, когда бригада не пришла. Причина переноса — сырой последний комментарий, его ещё надо прочитать и пересказать.
Появились. А1 (менеджер ждёт робота, пока клиент на линии), А2 (снимок десятиминутной давности — перенесли или нет?), А3 (WFM сломан — менеджер должен помнить ручной путь, а держать его в голове уже никто не будет).
Ценность, которой нет в ТЗ.
- Сигнал о переносе менеджеру без запроса, в момент изменения в WFM [Г].
- Черновик сообщения клиенту: «Выезд перенесён на …, причина: …». Менеджер правит и отправляет сам (J0).
- Причина из комментария, сведённая к понятной категории («нет доступа в серверную», «нет оборудования») с тем, что делать дальше [Г].
SC2 · «Почему заблокировали, мы же оплатили» · J1 · R1, R0
Сейчас.
1. Клиент звонит в раздражении (О у R0).
2. R1 в Старте по ИНН перебирает лицевые счета по одному: у одного ИНН их может быть много [Ф] personas, FR-SRCH-06 (П, ПП).
3. По каждому смотрит задолженность, тип блокировки, оплаты за период.
4. Проверяет CRM: нет ли исходящей претензии клиенту, о которой менеджер не знает [Ф] FR-WORK-10 (П).
5. Ценность: объяснение «оплата пришла на счёт Y, а блокировка на счёте X» [Г типовая причина] и путь к снятию.
По ТЗ. Сильнейший сценарий первой фазы: всё нужное в составе MVP [Ф] раздел 14.
- Убирает: перебор счетов (FR-SRCH-06, FR-CARD-09, AT-13, AT-15), поиск блокировки и её типа (FR-DATA-09), финансы за два года с выбором периода (FR-DATA-08), обе стороны претензий (FR-WORK-10).
- Внеплановое обновление финансов предусмотрено «в претензионном сценарии» [Ф] 7.3.
Остались. Снятие блокировки или уточнение платежа — в другой системе (ДС) [Г: в ТЗ не описано, где это делается]. Свежий платёж может не попасть в снимок со сроком свежести 30–60 минут [Ф] 7.3, отсюда спор «мы же оплатили» внутри самой витрины. Распознавание перекоса между счетами вынесено в развитие [Ф] FR-DATA-13 — а это и есть ответ на вопрос клиента.
Появились. А1, А2 (по деньгам особенно опасно: снимок может отставать от источника), А5 при наплыве звонков в день блокировок [Г].
Ценность, которой нет в ТЗ.
- Сигнал до блокировки: «по счёту X скоро блокировка, оплата этого клиента пришла на счёт Y». Нужны регулярные финансовые данные по всему портфелю, а не по открытой карточке.
- Предупреждение клиенту до блокировки, которое готовит помощник и отправляет человек (J0).
- Объяснение причины одной фразой для клиента, со ссылкой на факты (развитие FR-CARD-06).
SC3 · Запрос акта сверки · J2 · R1
Сейчас.
1. Клиент просит акт сверки (письмо может прийти в ЕСЭД без ИНН [Ф] прил. А, ЕСЭД) (ПП).
2. R1 находит лицевой счёт в Старте, переходит в Wcrep или РСО, снова вводит счёт и период (П, ПП, ДС).
3. Отчёт в Wcrep может формироваться долго [Ф] прил. А (О).
4. Отправка клиенту через ЭДО или почту, способ доставки известен из карточки [Ф] раздел 5 «способ доставки счетов».
5. Ценность: документ у клиента в одном контакте.
По ТЗ.
- Убирает: поиск счёта и способа доставки, поиск уже готовых документов в ЭДО или Электронном архиве (FR-DATA-05, FR-DATA-10).
- Действие не убирает: формирование и отправка не входят в MVP, только переход [Ф] FR-DATA-12; запись — в четвёртой фазе [Ф] FR-WORK-08. Если прямой ссылки нет, вместо неё «инструкция навигации» [Ф] FR-CARD-07, то есть повторный поиск в Wcrep остаётся.
Остались. ДС, ПП, О (длинное формирование в Wcrep).
Появились. Мелкие: А2 по реквизитам доставки. Главное другое: витрина приводит к двери и останавливается — по этому сценарию польза для R1 низкая.
Ценность, которой нет в ТЗ.
- Подготовленное действие: витрина уже знает счёт, период, способ доставки и адресата. Помощник собирает параметры и черновик сопроводительного письма, открывает Wcrep на нужной форме; кнопку «сформировать» и «отправить» нажимает человек [Г, согласовать с ИБ: это ввод в источник, но не запись от имени системы].
- Распознавание просьбы «пришлите акт сверки» в письме без ИНН и привязка к клиенту [Г].
SC4 · Утро менеджера: что горит по срокам · J3 · R1, R4
Сейчас.
1. R1 по очереди открывает МУЗ, ЕСЭД, CRM, HelpMe, ДК и смотрит свои очереди (П × 5).
2. В голове сводит, что ближе к сроку (ЗГ).
3. Письма ЕСЭД без клиентского ключа приходится вручную относить к клиенту [Ф] прил. А (ПП).
4. Обращение с неверной тематикой уходит не туда и висит [Ф] personas, FR-WORK-07.
5. Ценность: список «сделать сегодня, чтобы не просрочить» до первого звонка клиента.
По ТЗ.
- Убирает: общую ленту открытых обращений (FR-WORK-01), подсветку приближения срока по правилам (FR-WORK-05), уведомления о просрочках в составе контура [Ф] раздел 2.3.
- HelpMe — во второй фазе, неверная тематика — Could [Ф].
- Не определено главное: строится ли лента по всем открытым обращениям менеджера (обход очередей) или по клиентам, чьи карточки открывали [Ф] 01-roles, J3.
Остались. ЗГ по правилам срока, если правила не согласованы [Ф] раздел 15 «Неоформленные бизнес-правила — ложные алерты».
Появились. А4 — самая опасная потеря сценария. Если лента собирается от карточек, обращение клиента, которого сегодня не открывали, в неё не попадёт. Сейчас менеджер хотя бы сам листает очереди, а с витриной получит ложное спокойствие: лента пустая, значит ничего не горит [Г]. Плюс А3: сломался адаптер CRM — пропала треть ленты.
Ценность, которой нет в ТЗ.
- Постоянный обход очередей по расписанию (это список, а не карточка: подходит штатная выгрузка, ступень 1 из ui-integration.md).
- Утренняя сводка, которая приходит сама: «3 обращения просрочатся сегодня, у одного неверная тематика, письмо без ИНН похоже на клиента N» [Г].
- Явная отметка полноты ленты: «CRM не обновлялась с 07:10» вместо тихой дыры.
SC5 · Сделка застряла на техвозможности и ТЭО · J4, J5 · R2
Сейчас.
1. Лид в Лид-менеджменте → проект в ДК → заявка в Гермесе → проверка по адресу в 5ГИС (П × 4).
2. В Гермесе «много переходов и сохранений, итог не полностью виден в ДК» [Ф] прил. А.
3. Сделка ждёт расчёта в другом отделе. Сколько дней и у кого — никто не видит (О у сделки и у клиента, ПЗ).
4. Проверка, не в ликвидации ли клиент и нет ли долгов, — в отдельной системе [Ф] personas (П).
5. Ценность: «да, подключим, вот срок и цена» до того, как клиент ушёл к другому оператору [Г].
По ТЗ.
- В первой фазе для R2 почти ничего: Гермес, проверка окупаемости (FR-WORK-06, Should) и техвозможность по адресу (FR-AN-07, фаза 2а) — позже [Ф] раздел 14. Лид-менеджмент — P3 [Ф] 2.2.
- Карточка клиента показывает его проекты, но R2 нужен не клиент, а все его сделки сразу.
Остались. О и ПЗ: застрявшая сделка не подаёт сигнала. Ответ «можно ли по адресу» — только после фазы 2а.
Появились. А3 и А7 по Гермесу: длинный экранный путь — много точек поломки (см. SC9). А1 при каждом открытии сделки.
Ценность, которой нет в ТЗ.
- Воронка «мои сделки»: этап, дней на этапе против нормы, кто держит. Это «как должно / как есть» в чистом виде (сильная сторона БОС).
- Сигнал «сделка стоит на ТЭО дольше нормы» руководителю расчётного отдела и R2 [Г].
- Быстрый ответ по адресу отдельной функцией, лучше через выгрузку или справочник, а не через робота [Г].
SC6 · Перенос выезда в проекте, о котором никто не спросил · J6 · R3, R0
Сейчас.
1. В WFM бригада переносит выезд, пишет в комментарии «нужен доступ в серверную» [Ф] personas.
2. В Старте этого не видно до закрытия наряда [Ф] прил. А.
3. Цепочку МУЗ → ДК → Гермес → Старт → WFM целиком никто не видит [Ф] personas, FR-WORK-04.
4. R3 узнаёт, когда клиент звонит с жалобой (ПЗ, О у R0, НС).
5. Ценность (которой сейчас нет): R3 узнаёт о сбое в момент записи комментария и решает вопрос доступа до визита.
По ТЗ.
- Убирает: связь объектов в цепочку (FR-WORK-04, Must), подъём переноса выезда в число критичных событий (UX-03).
- WFM — вторая фаза, Should [Ф] FR-WORK-03.
- Обновление запускается открытием блока или приближением срока [Ф] 7.3. Перенос выезда — не срок обращения, и если карточку проекта никто не открыл, робот за ним не пойдёт [Г, вытекает из 7.3].
Остались. ПЗ целиком: в этом сценарии витрина по ТЗ почти не создаёт ценности. Причина задержки остаётся в свободном тексте.
Появились. А4 в предельной форме: сигнал получает только тот, кто сам зашёл посмотреть, а значит это уже не сигнал. Связь объектов «по утверждённым ключам» [Ф] FR-WORK-04: на стыке пяти систем часть связей будет помечена как неподтверждённая, и цепочка порвётся там, где нужна больше всего [Г].
Ценность, которой нет в ТЗ.
- Постоянный обход открытых нарядов и выездов по всем проектам. Открытых работ гораздо меньше, чем клиентов, поэтому обход посилен даже роботам по расписанию [Г].
- Сигнал R3 и R1 «как должно — выезд 12-го; как есть — перенос, причина: нет доступа» и подготовленное действие: письмо клиенту с просьбой обеспечить доступ.
- Предупреждение клиента до несостоявшегося визита (J0).
SC7 · Руководитель перед планёркой ищет причины роста просрочек · J7 · R4, S1
Сейчас.
1. R4 просит сотрудников прислать данные или выгружает вручную из нескольких систем [Г] (О, П).
2. Сводит в таблицу, причины задержек достаёт из комментариев и разговоров (ЗГ).
3. Ценность: «просрочки растут, потому что этап X стоит у отдела Y» — решение на планёрке, а не сбор данных.
По ТЗ.
- Дашборд просрочек — Should, третья фаза; отчётность по сотрудникам — вторая фаза после утверждения методики [Ф] FR-AN-01, FR-AN-05, раздел 14.
- Показатели — «только по фактически собранным данным» [Ф] FR-AN-04. Массовые выгрузки исключены из MVP [Ф] FR-AN-06.
- Честность учёта есть: отсутствие данных не считается нулём [Ф] FR-AN-03.
Остались. ЗГ по причинам задержек: в ТЗ нет разбора свободных комментариев. Сбор данных вручную до третьей фазы.
Появились. А6 — главная. Роботы собирали данные по тем клиентам, которых кто-то открывал. Забытый клиент с просроченным обращением в статистику не попадёт, хотя именно он и есть проблема [Ф] personas, раздел 4. Руководитель получит аккуратный, но смещённый график и примет по нему решение. Это хуже, чем таблица от сотрудников, потому что выглядит как полные данные [Г].
Ценность, которой нет в ТЗ.
- Причины задержек из свободных комментариев нарядов и обращений, сведённые в категории: «нет доступа», «нет оборудования», «ждём клиента», «ждём расчёта» [Г].
- Узкие места процесса («этап ТЭО держит проекты дольше нормы»), а не рейтинг сотрудников. Иначе отчётность воспримут как надзор [Г] personas.
- Для S1: короткая еженедельная картина управляемости с объяснением, откуда цифра.
SC8 · Новичок впервые готовит ответ на претензию · J8 · R5
Сейчас.
1. R5 получает претензию в CRM, не знает, где смотреть историю клиента: в МУЗ «история клиента обычно ищется в других ИС» [Ф] прил. А.
2. Спрашивает опытного коллегу, где что и что значит статус (О у R5 и у коллеги, ЗГ).
3. Собирает факты из Старта и ЕСЭД (П, ПП), пишет ответ, не уверен в формулировке.
4. Ценность: верный ответ клиенту без помощи коллег.
По ТЗ.
- Убирает: поиск фактов (карточка), подсказки «где источник, что означает статус, куда идти дальше» (UX-06, Should), «формализованные сценарии и подсказки по следующему действию» [Ф] раздел 1.2.
- Резюме по клиенту только на отображённых фактах — Could [Ф] FR-CARD-06.
Остались. Как отвечать на претензию по существу: регламент, сроки, формулировки. В ТЗ подсказки — про навигацию по витрине, не про работу.
Появились. А3 у новичка опаснее, чем у опытного: при сбое блока он не знает ручного пути [Г].
Ценность, которой нет в ТЗ.
- Помощник на базе знаний: «как разобрать претензию такого типа: шаги, сроки, где смотреть». Pro-znaniya уже есть в списке источников [Ф] 2.2, P3. Роботы для этого не нужны.
- Черновик ответа на претензию, собранный из фактов карточки со ссылками на источник; правит и отправляет человек [Г].
SC9 · Экран Гермеса изменился после релиза · J9 · R6, R2, R3
Сейчас. Сценария не существует: это потеря, которую создаёт выбранная архитектура (А7) [Ф] 01-roles, раздел A.
По ТЗ.
1. Владельцы Гермеса выпускают релиз; предупреждать о нём их ничто не обязывает [Г].
2. Адаптер видит несовпадение экрана → UI_CHANGED, новые данные не публикуются [Ф] RPA-02, AT-06.
3. Блок Гермеса у всех R2 и R3 замораживается со временем последнего успеха [Ф] AT-05, NFR-08.
4. Автоматический инцидент при росте UI_CHANGED [Ф] OPS-03; дежурный действует по инструкции без знания кода [Ф] OPS-04.
5. Правка адаптера → регрессия на тестовых клиентах [Ф] RPA-11 → постепенный выпуск [Ф] OPS-05 (Should).
6. Всё это время R2 и R3 работают в Гермесе вручную, то есть как до витрины, плюс знание, что блок сломан (А3).
Сильное в ТЗ: остановиться, а не показать ошибочное значение [Ф] раздел 4.1; изоляция адаптеров [Ф] NFR-08. Написано человеком, который знает предмет [Ф] ui-integration, раздел 6.
Потери. Гермес — длинный путь с множеством переходов и сохранений [Ф] прил. А, значит точек поломки больше, чем у других систем [Г]. Проверка «экран тот же» не гарантирует, что значение прочитано верно; нет плановых проверок на эталонных клиентах [Ф] ui-integration, раздел 6.
Ценность, которой нет в ТЗ.
- Договорённость с владельцами Гермеса: предупреждение о релизе и тестовый стенд. Организационный рычаг, главный по надёжности [Ф] ui-integration, раздел 6.
- ИИ-помощник для R6: сравнивает старый и новый экран, предлагает правку; публикует человек после стенда [Ф] ui-integration, раздел 2.
- Перевод Гермеса на выгрузку или API группы, если это разрешат: каждая система, ушедшая с экрана, убирает свою долю А3 и А7 навсегда [Ф] ui-integration, раздел 4.
J0 · Быть в курсе без звонка · R0 (в ТЗ нет)
Сейчас. Клиент узнаёт о переносе, блокировке, задержке проекта последним или по факту (бригада не пришла, связь отключена). Его единственный инструмент — звонок менеджеру, и этот звонок запускает SC1 и SC2 [Ф] personas, раздел 7.
По ТЗ. Ничего: клиент не пользователь витрины, его сценариев нет [Ф] 01-roles, R0. Уведомления в ТЗ — для сотрудников [Ф] раздел 2.3.
Потеря. Каждый звонок «где выезд» и «почему блокировка» — это работа, порождённая отсутствием проактивности. Витрина ускоряет ответ на такой звонок, но не убирает сам звонок.
Ценность, которой нет. Цепочка «событие в системе → сигнал менеджеру → черновик сообщения клиенту → менеджер нажимает "отправить"». Человек остаётся в контуре, поэтому это не автономная операция и не противоречит ТЗ [Ф] раздел 2.3 «вне контура: автономное выполнение значимых операций». Канал (почта, ЭДО, мессенджер) — уточнить [Г].
2. Сводная таблица работ
Типы данных:
- Т1 — точечные свежие данные по одному клиенту, по запросу;
- Т2 — постоянный обход всех открытых работ (обращений, нарядов, сделок);
- Т3 — полные регулярные данные по всем клиентам за период;
- Т4 — знание: маршруты, правила, значения статусов, регламенты.
| Работа |
Роль |
Тип данных |
Подходят ли роботы по запросу |
Где ценность сильнее всего |
| J1 · ответить на вопрос |
R1 |
Т1 (+Т4 для причин) |
Да, ради этого спроектированы. С оговорками: А1 на линии, А2 по деньгам; ночная предзагрузка портфеля снимает большую часть [Ф] ui-integration, раздел 5 |
SC2 в первой фазе; SC1 — только со второй фазы (WFM) |
| J2 · выполнить действие |
R1 |
Т1 |
Да для чтения; само действие витрина не делает [Ф] FR-DATA-12 |
Подготовленное действие: параметры и черновик, нажимает человек |
| J3 · не пропустить срок |
R1, R4 |
Т2 |
Нет. Нужен обход очередей по расписанию; роботы «по карточке» дают ложное спокойствие |
Утренняя сводка, которая приходит сама; отметка полноты ленты |
| J4 · довести сделку |
R2 |
Т2 |
Нет. Нужен обход открытых сделок; Гермес — хрупкий экранный путь |
Воронка «сколько дней на этапе против нормы» |
| J5 · ответ по адресу |
R2 |
Т1 (по адресу, не по клиенту) или справочник |
Частично; фаза 2а; лучше выгрузка или справочник [Г] |
Первый контакт с новым клиентом |
| J6 · проект в срок |
R3 |
Т2 |
Нет. Сигнал по открытию карточки — не сигнал |
Перенос выезда и причина из комментария в момент записи |
| J7 · узкие места |
R4, S1 |
Т3 |
Нет. Картина смещена (А6); массовые выгрузки исключены |
Причины задержек из комментариев; узкие места процесса |
| J8 · новичок |
R5 |
Т4 (+Т1 для фактов) |
Не нужны для знания |
Помощник «как разобрать претензию»; черновик ответа |
| J9 · роботы в строю |
R6 |
данные о самих роботах |
Не применимо: это цена архитектуры |
ИИ-помощник при ремонте; договорённость о релизах; уход систем с экрана |
| J10 · правомерность доступа |
R7 |
журнал |
Не применимо: журнал нужен именно потому, что учётка робота широкая [Ф] ui-integration, раздел 8 |
Ограничение «менеджер видит только своих клиентов»; меньше широких учёток |
| J0 · быть в курсе без звонка |
R0 |
Т2 (события по открытым работам) |
Нет |
Сообщение клиенту до того, как он позвонит |
Чтение таблицы. Роботы по запросу честно обслуживают одну работу (J1) и чтение для J2. Пять работ (J0, J3, J4, J6, J7) требуют обхода или полных данных. Одна (J8) вообще не про данные.
3. Моменты ценности по ролям
Хрупкость — насколько момент зависит от того, что робот успел и смог прочитать: высокая / средняя / низкая (качественная оценка).
| Роль |
Момент, когда впервые чувствуется польза |
Когда наступает по ТЗ |
Хрупкость |
Почему |
| R1 |
Клиент на линии, менеджер за один поиск видит все лицевые счета, блокировку и оплаты и отвечает, не прося перезвонить (SC2) |
Первая фаза |
Средняя |
Держится на кэше и предзагрузке; одна долгая загрузка или устаревшая сумма при клиенте — и доверие уходит [Г] |
| R1 (выезд) |
Менеджер называет новую дату выезда, а не старую из Старта (SC1) |
Вторая фаза |
Высокая |
Зависит от WFM, свежести снимка и стабильности адаптера |
| R2 |
Видит все свои сделки и где каждая стоит (SC5) |
В ТЗ нет как такового |
Высокая |
Гермес — хрупкий путь; обхода всех сделок нет |
| R3 |
Узнаёт о переносе выезда раньше клиента (SC6) |
По ТЗ фактически не наступает |
Очень высокая |
Без постоянного обхода сигнал приходит, только если сам открыл карточку |
| R4 |
Готовится к планёрке за минуты, и цифре можно верить (SC7) |
Третья фаза |
Высокая |
Смещённая выборка (А6) подрывает доверие при первом же «а где клиент N?» [Г] |
| R5 |
Впервые ответил клиенту правильно, не спросив коллегу (SC8) |
Подсказки — Should, без указания фазы |
Низкая для знания |
Знание не зависит от роботов; факты зависят |
| R6 |
Починил сломавшийся адаптер по инструкции за одну смену (SC9) |
Первая фаза (OPS-04) |
Средняя |
Зависит от договорённостей с владельцами систем, а не от кода |
| R7 |
Ответил на запрос проверки по журналу за один поиск |
Первая фаза (SEC-05, FR-SRCH-05) |
Низкая |
Журнал — внутренняя часть витрины |
| R0 |
Получил сообщение о переносе до того, как прождал бригаду |
В ТЗ нет |
— |
Появится только с Т2 и проактивным сообщением |
| S1 |
Увидел на одной странице, где компания теряет сроки и почему |
В ТЗ — раздел руководителя во второй-третьей фазе |
Высокая |
Та же А6 плюс отсутствие разбора причин |
Главное. Самый ранний и надёжный момент ценности — у R1 в SC2. Моменты, которые зацепили гендира (управляемость, сигналы, «как должно / как есть»), по ТЗ либо наступают поздно, либо не наступают вовсе.
4. Ценность, которой нет в ТЗ (сводно)
| Ценность |
Для кого |
Сценарии |
Что нужно под капотом |
| Проактивность для клиента: сообщение до звонка, черновик — помощник, отправка — человек |
R0, R1, R3 |
SC1, SC2, SC6, J0 |
Т2: обход открытых работ и событий |
| Сигналы без запроса: перенос выезда, сделка дольше нормы, обращение скоро просрочится, блокировка на подходе |
R1, R2, R3, R4 |
SC1, SC2, SC4, SC5, SC6 |
Т2 и правила «как должно» |
| Подготовленное действие: параметры, черновик, переход на нужный экран; нажимает человек |
R1, R5 |
SC3, SC8, SC6 |
Т1 + шаблоны; согласование с ИБ [Г] |
| Знание для новичка: где смотреть, что значит статус, как отвечать на претензию |
R5, R1 |
SC8, SC1 (WFM) |
Т4; роботы не нужны |
| Причины задержек из свободных комментариев |
R3, R4, S1 |
SC6, SC7, SC1 |
Т2/Т3 + смысловой разбор текста |
| Привязка писем без ИНН и обращений с неверной тематикой |
R1 |
SC3, SC4 |
Т2 по очередям + смысловой разбор |
| Отметка полноты: «эта лента не видит CRM с 07:10» |
все |
SC4, SC7 |
уже частично в ТЗ (FR-AN-03, UX-02); довести до лент и дашбордов |
Всё это — то, что делает БОС: «как должно / как есть», сигнал на расхождение, помощник, решение за человеком.
5. Выводы для позиции и предложения
- Принять сильную часть ТЗ без спора. Карточка для R1 (SC2 в первой фазе) — реальный и ранний момент ценности. Требования к честности данных (источник, время, остановка при изменении экрана, конфликты рядом) написаны грамотно; на них стоит опереться, а не переписывать.
- Показать разрыв по типам данных. Роботы по запросу закрывают J1 и чтение для J2. J3, J4, J6, J7 и J0 требуют постоянного обхода открытых работ или полных регулярных данных. Если строить их на карточках, появятся ложное спокойствие (SC4), сигнал, который не приходит (SC6), и смещённая аналитика (SC7). Это главный аргумент предложения, и он вытекает из самого ТЗ (раздел 7.3, FR-AN-04, FR-AN-06).
- Предложить обход открытых работ как отдельный режим. Открытых обращений, нарядов и сделок гораздо меньше, чем клиентов; их можно обходить по расписанию через штатные выгрузки (ступень 1) или выгрузки группы (ступень 0). На этом фундаменте и стоят сигналы БОС [Г: объём открытых работ уточнить].
- Дать клиенту то, ради чего всё делается. Проактивное сообщение (J0) превращает витрину из «быстрее отвечать на звонок» в «звонков меньше». Человек нажимает «отправить» — значит, в рамках принципов ТЗ.
- Знание — первым и отдельно. Помощник для R5 («где смотреть, что значит, как ответить на претензию») не зависит от роботов, даёт самый устойчивый момент ценности и может показать результат раньше любого адаптера. Метрика «срок обучения» уже есть в ТЗ (раздел 1.2).
- Честно пометить, чего нет в первой фазе. SC1 без WFM даёт менеджеру тот же неверный статус из Старта. Предложить либо поднять WFM в первую фазу, либо явную отметку в карточке «перенос выезда не виден до закрытия наряда».
- Довести действие до кнопки, а не до двери. В SC3 витрина приводит к Wcrep и останавливается. Подготовленное действие (параметры + черновик + переход, нажимает человек) даёт заметную пользу без записи в источники, а запись четвёртой фазы потом ложится на готовое.
- Считать цену архитектуры в людях и сокращать её. R6 и R7 существуют только из-за экранного чтения. Каждая система, переведённая на выгрузку (первые кандидаты — длинные и хрупкие пути вроде Гермеса), убирает свою долю дыр (А3) и сопровождения (А7). Рычаги: договорённость с владельцами систем о релизах и ИИ-помощник при ремонте под контролем человека.
Что проверить у заказчика, чтобы закрепить выводы: как строится лента в SC4 (по очередям или по карточкам); сколько открытых работ одновременно у R1, R2, R3; где снимается блокировка и уточняется платёж (SC2); можно ли открыть Wcrep с заполненными параметрами (SC3); каким каналом можно писать клиенту (J0).