Карта метрик продаж (дерево + покрытие)

Карта метрик продаж ITECH (Grace)

Дерево показателей системы управления продажами Баранова, разложенное до операционных драйверов и сшитое с реальными полями itech_*. Каждая метрика помечена покрытием — где данных нет, написано честно «нет источника», чтобы дашборд не врал. Ось всей модели = продажа часов (план меряется в нормо-часах; рубли и маржа производны). Проверено на 89, 2026-06-20.

Как читать

Формат строки: метрика → формула → тип → уровень → владелец → источник itech_* → покрытие.

Тип: Р результат (lagging, что меряем по факту) · Д драйвер (leading, на что команда влияет) · К коэффициент/норматив.
Уровень дерева: L0 вершина бизнес-плана · L1 декомпозиция результата · L2 драйвер воронки · L3 операционный/коэффициент.
Владелец (этап воронки): ПРЕ прескрипция · РАС расчёты/КП · ПРО продажи/коммерция · ИСП исполнение/производство.
Покрытие: ✅ есть (поле заполнено надёжно) · 🟡 частично (есть, но пробелы/датировка слабая) · ❌ нет источника (в данных не captured — драйвер известен, но не считается).

L0 — вершина бизнес-плана (результаты Баранова)

Метрика	Формула	Тип	Владелец	Источник `itech_*`	Покрытие
Годовой оборот, руб.	`Σ order_amount` по реализованным	Р	ПРО+ИСП	`orders.order_amount`	✅ есть
Выработка нормо-часов (ось плана)	`Σ total_hours_fact` (план: `total_hours_plan`)	Р	ИСП	`orders.total_hours_*`	🟡 present 100%, содержательно (часы>0) 43% = 1996 заказов-производство; Товары/Услуги=0. Σ=789 289 ч
Маржинальная прибыль чистая, руб.	`Σ margin_amount`	Р	ПРО+ИСП	`orders.margin_amount`	✅ 100% (реальна с 2024)
Маржинальность чистая, %	`Σ margin_amount / Σ order_amount`	Р	ПРО	`orders`	✅ есть (2024+)
Кол-во проектов, шт.	`count(distinct project_id)`	Р	ПРО	`projects`	✅ есть

L1 — декомпозиция результата

Метрика	Формула	Тип	Уров.	Владелец	Источник	Покрытие
⭐ Маржа на нормо-час	`margin_amount / total_hours_fact`	Р	L1	ИСП	`orders`	🟡 только заказы с часами>0 (1996); у Товаров не определена (0 часов)
Оборот по линиям (НКУ/СН/Товары/Услуги)	`Σ order_amount` по `ТипСчёта+вольтаж`	Р	L1	ПРО	`order_items` / линия	🟡 классиф. линии в items
Средний чек	`оборот / кол-во сделок`	Р	L1	ПРО	`orders`	✅ есть
Кол-во закрытых сделок	`count(status='Закрытие сделки')`	Р	L1	ПРО	`projects.status`	✅ срез / 🟡 динамика
Структура затрат (ПерЗ/ПостЗ/Трасх)	`В − margin`; ПостЗ = часы×Сп	Р	L1	ИСП	`orders.total_cost`	🟡 агрегат, без разбивки
Маржа по объекту	`Σ margin` ⋈ `properties`	Р	L1	ПРО	`projects.property_id`→`properties`	🟡 объект 79%
Маржа по отрасли/типу объекта	`Σ margin` ⋈ `sector`/`property_type`	Р	L1	ПРО	`properties.sector` + `property_type`	🟡 sector 35%; property_type гранулярнее (тип здания, нужен `.keyword`)
Маржа по региону объекта (доставка)	`Σ margin` ⋈ регион из адреса	Р	L1	ПРО	`properties.address_full` (парсинг)	🟡 адрес 99.8%, регион парсится (поле `region` пусто)
Маржа по отрасли/региону клиента	`Σ margin` по обогащённому ИНН	Р	L1	ПРО	ИНН-обогащение (внешн.)	❌ Grace пусто → строим (см. ниже)

L2 — драйверы воронки (leading) по владельцам

ПРЕ — Прескрипция (посев на стадии проектирования)

Метрика	Формула	Тип	Источник	Покрытие
Кол-во регистраций (вход воронки)	`count(projects, type='Прескрипция')` по `created_at`	Д	`projects` (`type_of_calculation`)	🟡 тип заполнен ~50%
Кол-во объектов в проработке	`count(distinct property_id)` в прескрипции	Д	`projects.property_id`→`properties`	🟡 объект 79%
Конверсия Регистрация→Работа П→Р→Выполнено	переходы по стадиям прескрипции	Д	`projects.status` + снапшот	❌ переходы не датированы (`status_updated_at` 53% пуст)
Повторные посевы на объект	объект с >1 проектом во времени	Д	граф `properties.accounts`	🟡 (через объект)

РАС — Расчёты / подготовка КП

Метрика	Формула	Тип	Источник	Покрытие
Кол-во подготовленных КП	`count(status='Отправлено КП')`	Д	`projects.status`	🟡 срез есть, поток — нет
SLA расчёта (норматив 8ч/заявка)	`время(заявка → КП)`	Д	`calculations/*`	❌ API заблокирован (LEV-147), нет таймстемпа КП
Очередь расчётов / WIP	кол-во заявок «в расчёте» сейчас	Д	стадия расчёта	❌ не captured без снапшота
Точность маржи (факт vs расчёт)	`margin_fact − margin_расчёт`	Д	факт `orders` / расчёт `calculations`	❌ расчётная часть заблокирована; факт ✅
Загрузка инженеров (часы факт)	`Σ time` тайм-трекинг / норму	Д	`engineer_worklog` (открыт, LEV-147)	🟡 источник открыт, не в витрине

ПРО — Продажи / коммерция

Метрика	Формула	Тип	Источник	Покрытие
Кол-во отправленных КП	`count(status='Отправлено КП')`	Д	`projects.status`	🟡 срез / поток нужен снапшот
Win-rate (внешний тендер)	`закрыто / (закрыто+проиграно)` по терминалам	Д	`projects.status` + `type`	🟡 терминалы есть, датировка слабая
Win-rate (внутренний тендер)	то же по внутр. воронке	Д	`projects.status` + `type`	🟡 то же
Конверсия КП→Согласование→Закрытие	переходы стадий	Д	`projects.status` + снапшот	❌ переходы не датированы
Цикл сделки (дни)	`cycle_time_days`	Д	`orders.cycle_time_days`	🟡 есть в заказах
Активность ~~менеджера~~/ ~~(звонки/задачи)~~событийный поток по сделке	`count(reminders/tasks)comments)` по автору/сущности/периоду; дней с последнего касания	Д	`itech_remindersitech_comments` (120k: автор+дата+текст)	❌🟡 ~~ПУСТ,~~derived не(`reminders` ~~captured~~пуст, но comments живые и растут)
Соблюдение маржинальности (анти-демпинг)	цена↑ при рентабельности↓	Д	`orders` + `order_items`	🟡 считается из факта

ИСП — Исполнение / производство

Метрика	Формула	Тип	Источник	Покрытие
Выполнение плана по часам	`total_hours_fact / total_hours_plan`	Р/Д	`orders.total_hours_*`	🟡 план 62% / факт 43%
Маржа факт (по реализации)	`margin_amount` на отгрузке	Р	`orders.margin_amount`, `shipping_date_fact`	✅ 100%
Цикл производства	`cycle_time_days` / `status_production_id`	Д	`orders`	🟡 есть
Часы по линиям (НКУ/СН/Товары/Услуги)	`Σ hours` по линии	Д	`order_items` + норматив часов	🟡 норматив артикулов

Клиентская база и приток (⚠️ карточки ≠ клиенты)

Проверено на 89: всего карточек контрагентов 7643, из них покупателей (order_count>0) — 751 (10%), лидов без заказов — 6892 (90%); активных (last_order_at ≥ 2025) — 290. Дата создания карточки не годится как приток: 2020 = 3203 карточки (дамп миграции, не привлечение) + 90% карточек мёртвые.

Метрика	Формула	Тип	Уров.	Владелец	Источник	Покрытие
⭐ Приток новых покупателей / период	контрагент с первым заказом в периоде = `min(orders.created_at)` по `account_id`	Д	L1	ПРО	`orders.account_id`+`created_at` (витрина)	🟡 считается в витрине (НЕ `accounts.created_at`)
Активная клиентская база	`count(accounts, last_order_at ≥ окно)`	Р	L1	ПРО	`accounts.last_order_at`, `order_count`	✅ (290 с 2025)
Конверсия лид→покупатель	`покупатели / всего карточек`	Д	L2	ПРО	`accounts.order_count`	✅ (751/7643 ≈ 10%)
Отток / спящие	был заказ, но `last_order_at` вне окна	Д	L2	ПРО	`accounts.last_order_at`	✅
Концентрация выручки на клиенте	доля топ-клиента; ≥15% = зависимость	Д	L2	ПРО	`accounts.revenue_mln`	✅
❌ «Новые карточки / период»	`count(accounts) by created_at`	—	—	—	`accounts.created_at`	❌ не использовать как приток (дамп 2020 + 90% без заказов)

Портрет покупателя + обогащение по ИНН

Проверено на 89 (покупатели, 751): у клиентов sectors (отрасль) и region ПУСТЫ, но inn есть у 100%. → отрасль и регион клиента не из Grace, а обогащением по ИНН из внешнего реестра (Dadata/ЕГРЮЛ/ФНС-открытые/Контур.Фокус). Это параллельный трек ELT-«дообогащения» (живёт в слое нормализации ArangoDB на 147), не блокирует витрину.

Две разные оси — не путать: объект (properties: sector/property_type building-derived + регион из address_full, ~100% адресов) = «куда/во что продаём»; клиент (ОКВЭД/регион по ИНН) = «кому продаём». Сектор Grace проставляет по зданию (property_type → sector).

Признак портрета	Источник	Покрытие
Роль контрагента (Покупатель/Поставщик/Субподряд/Проектировщик)	`accounts.account_types`	✅ (роли пересекаются)
Надёжность	`accounts.reliability`	🟡 ~30% (227/751)
Выручка / оплачено / долг	`accounts.revenue_mln`/`paid_mln`/`debt_mln`	✅
Заказы/проекты, последний заказ	`accounts.order_count`/`project_count`/`last_order_at`	✅
Только предоплата	`accounts.is_prepayment_only`	✅
⭐ Отрасль клиента (ОКВЭД)	❌ Grace пусто → ИНН-обогащение	строим
⭐ Регион/город клиента	❌ Grace пусто (`region` пуст) → ИНН-обогащение	строим
Размер (МСП/крупный), статус (действ./ликвид.), дата регистрации	ИНН-обогащение	строим
Отрасль/тип объекта (куда продаём)	`properties.sector` + `property_type` (building-derived)	🟡 sector 35%; тип здания гранулярнее
Регион/город объекта (доставка)	`properties.address_full` (парсинг)	🟡 адрес 99.8%; регион парсится

Портрет = (роль + надёжность + платёжная дисциплина из Grace) × (отрасль + регион + размер из ИНН) × (отрасль объекта). Под сегментацию, таргетинг допродаж и оценку нового лида ещё до сделки.

Слой комментариев (`itech_comments`, 120k) — качественный + активность

Отдельный индекс, полиморфный (commentable_type + commentable_id); у каждого комментария: comment (текст, ru-анализатор), author_name, created_at, денормализованы project_id/project_status/account_id/calculation_id. Растёт: 2023=16k → 2024=36k → 2025=53k (живой, в отличие от пустого reminders).

Привязка (топ): SupplyRequest 22k · PaymentRequest 15k · Delivery 11k · Contract 7.5k · ContractAnnex 6.4k · Project 6407 · ComponentDefect 6.2k · Problem 5.8k · Calculation 4347 · Account 2446 · Order 2259 · Task 2112; объекты: Property 107 + ObjectRegistration 264.

Что даёт Как Тип Покрытие Активность/застой сделки объём комментов + дней с последнего касания по проекту/расчёту Д 🟡 derived (заменяет пустой reminders) Нарратив воронки (возражения/блокеры/причины) NLP по Project+Calculation коммент. + projects.refusal_reason Д 🟡 derived (NLP) Качество/рекламации коммент. ComponentDefect/Problem/Reclamation Д 🟡 derived История сделки для агентов RAG/граф по коммент. (Onyx) — вход для агентов

⚠️ commentable_type именуется непоследовательно (Property vs Modules\Projects\Entities\Project) → нормализация типа (трек Arango). Комментарии не агрегируются как метрики напрямую — это производный слой: витрина берёт счётчики/скорость/NLP-метки, граф — события таймлайна, Onyx — RAG.

Модель «объект → проект» (корень и счётчики притока)

Порядок ввода в Grace: сначала объект (property), потом проект (цепляется через property_id), далее расчёт → заказ. Объект — корень модели и центральное измерение витрины/графа. itech_object_registrations (445) — мост регистрации.

Отсюда три раздельных счётчика притока (не путать): новые объекты (properties.created_at) · новые проекты (projects.created_year) · новые покупатели (первый заказ, min(orders.created_at) по account_id).

L3 — коэффициенты и нормативы (из Положения о премии / методики)

Показатель	Формула	Тип	Владелец	Источник	Покрытие
Кк — качество данных	доля корректно заполненных полей	К	все	`itech_quality_managers` (есть, Кк≈69.7%)	✅ есть
Ку — коэф. участия по стадии	норматив по стадии воронки	К	ПРО	Положение о премии §2.x	✅ норматив (не из данных)
Сп — ставка нормо-часа (3250/3660/4170)	норматив грейда	К	ИСП	Положение о премии §2.2	✅ норматив
Утилизация инженеров	`часы факт / доступный фонд`	К	ИСП	`engineer_worklog` + штат	🟡 фонд не в витрине
Премия П	`[Σ((Пр×Ку) − КРр)] × Кк`	К	ПРО	производная всех выше	🟡 собирается из частей

Сводка покрытия (что сразу, что закрыть)

Считаем сегодня (✅/🟡): оборот, маржа (сумма и %), маржа/час, средний чек, кол-во сделок, win-rate (как срез), цикл сделки, выполнение плана по часам, срезы по объекту/региону/линии, Кк. → этого достаточно для дашборда «план/факт по часам + рентабельность» v1.

Дыры → не выдумывать, закрыть инструментом (❌):

Поток воронки (конверсии, скорость стадий) — status_updated_at пуст 53%, переходы не датированы → лечится датированным снапшотом в ETL (см. LEV-171 шаг 3). ~~Это~~Частично ~~даёт~~восстановимо ~~Баранову~~из ~~динамику,~~itech_comments ~~которой~~(датированные усобытия ~~него~~активности ~~сейчас~~по ~~нет.~~сделке).
SLA расчёта / WIP / точность маржи — calculations/* API заблокирован (LEV-147) → нужны read-права API у ITECH.
Активность менеджера ~~(ранние стадии)~~ — itech_reminders ~~пуст~~пуст, НО itech_comments (120k, автор+дата) даёт активность-прокси и «застой сделки» → ~~либо~~дыра ~~включить~~закрывается вкомментариями ~~синк,~~(derived), ~~либо~~не ~~принять,~~пустым ~~что воронка стартует с «Регистрации».~~reminders.

Принцип карты: дашборд показывает только метрики с покрытием ✅/🟡; ❌-метрики выводятся как «требует данных X» — белые пятна видны, не маскируются нулём.

Refs: LEV-171 (витрина часов), LEV-169 (3 воронки), LEV-147 (часы/calc API), Положение о премии (BookStack, полка HR), Бизнес-план itech_1/docs/input/Бизнес план с формулами.xlsx, Стрелкова docs/Strelkova/generatory_pribyli.md.